RockScience,

I see two options here, they both enable you to inherit permissions, as opposed to passing in user and password credentials. To address your specific question, around Linux take a look at:

• Active Directory Authentication with SQL Server on Linux

If you take the approach of running Windows containers, take a look at Active Directory gMSA (Group Managed Service Accounts) accounts and the following MSDN article and video:

• Active Directory Service Accounts for Windows Containers

• Walk the Path to Containerization - transforming workloads into containers

this would enable you to create a Windows container and R environment.

Active Directory Authentication with SQL Server on Linux

The tutorial explains how to configure SQL Server on Linux to support Active Directory (AD) authentication, also known as integrated authentication. AD Authentication enables domain-joined clients on either Windows or Linux to authenticate to SQL Server using their domain credentials and the Kerberos protocol.

AD Authentication has the following advantages over SQL Server Authentication:

• Users authenticate via single sign-on, without being prompted for a password.
• By creating logins for AD groups, you can manage access and permissions in SQL Server using AD group memberships.
• Each user has a single identity across your organization, so you don’t have to keep track of which SQL Server logins correspond to which people.
• AD enables you to enforce a centralised password policy across your organisation.

The tutorial consists of the following tasks:

• Join SQL Server host to AD domain
• Create AD user for SQL Server and set SPN
• Configure SQL Server service keytab
• Create AD-based logins in Transact-SQL
• Connect to SQL Server using AD Authentication

Active Directory Service Accounts for Windows Containers

Today, group Managed Service Accounts are often used to secure connections between one computer or service to another. The general steps to use one are:

1. Create a gMSA
2. Configure the service to run as the gMSA
3. Give the domain-joined host running the service access to the gMSA secrets in Active Directory
4. Allow access to gMSA on the other service such as a database or file Shares

When the service is launched, the domain-joined host automatically gets the gMSA secrets from Active Directory, and runs the service using that account. Since that service is running as the gMSA, it can access any resources the gMSA is allowed to.

1. Windows Containers follow a similar process:
2. Create a gMSA. By default, a domain administrator or account operator must do this. Otherwise they can delegate the privileges to create & manage gMSAs to admins who manage services which use them. See gMSA Getting started
3. Give the domain-joined container host access to the gMSA
4. Allow access to gMSA on the other service such as a database or file Shares
5. Use the CredentialSpec PowerShell module from windows-server-container-tools to store settings needed to use the gMSA
6. Start the container with an extra option --security-opt "credentialspec=..."

When the container is launched, the installed services running as Local System or Network Service will appear to run as the gMSA. This is similar to how those accounts work on a domain-joined hosts, except a gMSA is used instead of a computer account.

Example Uses

SQL Connection Strings

When a service is running as Local System or Network Service in a container, it can use Windows Integrated Authentication to connect to a Microsoft SQL Server.

Example:

Copy

Server=sql.contoso.com;Database=MusicStore;Integrated Security=True;MultipleActiveResultSets=True;Connect Timeout=30

On the Microsoft SQL Server, create a login using the domain and gMSA name, followed by a $. Once the login is created, it can be added to a user on a database and given appropriate access permissions.

Example:

SQL

Copy

CREATE LOGIN "DEMO\WebApplication1$"    FROM WINDOWS    WITH DEFAULT_DATABASE = "MusicStore"GOUSE MusicStoreGOCREATE USER WebApplication1 FOR LOGIN "DEMO\WebApplication1$"GOEXEC sp_addrolemember 'db_datareader', 'WebApplication1'EXEC sp_addrolemember 'db_datawriter', 'WebApplication1'

To see it in action, check out the recorded demo available from Microsoft Ignite 2016 in the session "Walk the Path to Containerization - transforming workloads into containers".

As @Technophobe01 has shown a windows container would be a more natural fit for inheriting AD permissions.

In terms of getting the R script connected to your file shares and MS SQL Databases I would recommend the following

MS SQL Connection

Connect to databases using connection strings in the R script
This is a conventional approach rather than inheriting some permissions.
See SQL Server RODBC Connection

library(RODBC)conn <- odbcDriverConnect('driver={SQL Server};server=mysqlhost;database=mydbname;uid=user;pwd=pwd')

You can specify any sensitive fields using ENV vars at deploy time or docker secrets and load them into the R script.

File Shares

See https://blogs.msdn.microsoft.com/stevelasker/2016/06/14/configuring-docker-for-windows-volumes/
1. Map the network drives onto your Windows docker host
2. Specify them as available to containers in docker settings, you will need to add a new user account with admin privileges.
3. Assuming network drive is mapped to d:
docker run -v d:/somedata:/data <container> ls /data will mount the drive in the container at /data and list its contents.