4

My current services run on Windows in IIS. I have them run as a Service Account user that is part of my Domain. This user runs the app pool for the service and is also given the needed permissions to the database. Then our connection strings can just use integrated security to connect to our SQL Server databases.

The benefit of this is that it can be setup in advance and the code/connection strings do not need to have any passwords.

As I am moving to docker containers I am finding this a difficult situation to keep using. My containers run as root or some other non-company user. So I can't just use integrated security. (And even if I could make my containers run as a domain user, I don't know that it would be a good practice.)

How can I keep passwords out of my database connection strings and configuration when running in containers?

Vaccano
  • 78,325
  • 149
  • 468
  • 850
  • 1
    Am I correct to understand that "integrated security" is what Microsoft calls their spin on Kerberos? You do realize that Kerberos existed in the UNIX world _long_ before Active Directory existed, and it's still around and available to use today. – Charles Duffy Aug 03 '21 at 22:06
  • ...that said, generally, I'd suggest Hashicorp Vault if you're looking for a more modern secret-management stack designed for cloud use. That's a much broader question than is usually on-topic here (and closer to systems design or security than to programming; both of those fields have their own Stack Exchange site). – Charles Duffy Aug 03 '21 at 22:07
  • ...anyhow, if you were using a native-UNIX database, the krb5 connection / authentication / encryption method is where you'd find the Kerberos support. – Charles Duffy Aug 03 '21 at 22:09

1 Answers1

6

Couple options that might work depending on your specific scenario:

  1. If you're connecting to on-prem SQL Server database you can can use Integrated windows auth with Kerberos - see here for implementation of a .NET Core app, running in a Linux container, connecting to a SQL Server database with integrated security.
  2. You could also switch to SQL auth and get User Id and Password (or entire connection string) from Azure App Config / Azure Key Vault. Note: in AAC, any secrets settings (e.g. API keys, SSH keys, etc) should be Azure Key Vault (AKV) references. AAC can integrate to AKV via managed identity.
  3. If you're using managed DB like Azure SQL Database you could connect using DefaultAzureCredential with Azure Tenant ID & client ID/Secret (of AAD app registration) set as environment variables (see EnvironmentCredential which is the default credential type for DefaultAzureCredential). Note: for local development DefaultAzureCredential will fallback to VisualStudioCredential, which enables authentication to AAD from Visual Studio using user creds.
Ryan.Bartsch
  • 3,698
  • 1
  • 26
  • 52