[johnsimons]

ServiceControl can now sign in to PostgreSQL with a Microsoft Entra ID token or an AWS RDS IAM token instead of a password. This covers the EF Core PostgreSQL persisters of the primary and audit instances and the PostgreSQL transport, including its queue length provider and throughput query. Password connection strings work as before.

Managed PostgreSQL on Azure and AWS can require token sign-in, and the tokens expire after minutes or hours. ServiceControl passed the connection string straight to Npgsql, so it could not refresh a token. SQL Server already supports Entra ID through SqlClient's Authentication=Active Directory Default since #5786, and this PR adds the first test of that path.

Configuration

A keyword in the existing connection string turns token authentication on:

• Token Authentication=AzureEntraId gets the token from DefaultAzureCredential. ServiceControl derives the scope and authority host from the host name for the public, US Government and China clouds. For other host names, such as a custom DNS name, Token Scope=<https URI> sets the scope.
• Token Authentication=AwsRdsIam signs the token with the AWS SDK's default credentials and region. The connection string must name exactly one host, because an IAM token is signed for one host and port.

The connection string needs a Username and must not contain Password or Passfile. ServiceControl removes the keywords before Npgsql reads the string. A connection string without either keyword is not parsed at all, so a malformed password connection string fails in the same place as before.

An invalid value fails with an InvalidOperationException that names the setting: Database/ConnectionString, LicensingComponent/PostgreSQL/ConnectionString or the transport connection string.

No setting is added, so ServiceControl Management, PowerShell and container configuration need no change. The Help text in the transport manifest describes the keyword.

How it works

• The token code is in src/ServiceControl.PostgreSql.TokenAuthentication/, which has no project file. Both persisters and the transport compile it as linked source.
• Each connection pool uses an NpgsqlDataSource with a periodic password provider. It gets a new token every 5 minutes and tries again 10 seconds after a failure, which it logs as an error. Five minutes is well inside the 15-minute lifetime of an AWS token, and it limits how often AzureCliCredential starts a process, which it does on every call.
• The transport keeps one data source per connection string, shared by the endpoints, the queue length provider and the throughput query of an instance, so they refresh one token. The key is Npgsql's canonical form of the string, so one connection written two ways still shares a data source.
• The audit retention lock has its own unpooled data source, because a session lock would stay with a pooled connection after it returns to the pool.
• The persisters and the transport reference AWSSDK.SecurityToken, which AWSSDK.Core loads by name for web identity (EKS IRSA) and assume-role credentials. ServiceControl.Persistence.EFCore gets the same reference. Without it, --setup of a primary instance with S3 body storage and web identity credentials fails to load that assembly.

Alternatives considered

• Microsoft.Azure.PostgreSQL.Auth 1.0.0 instead of our own Azure provider. It hard-codes the public cloud scope, requests a management.azure.com token to find the user name, and gets a token on every connection open.
• SqlClient's keyword name, Authentication. A separate name avoids implying that SqlClient's other Authentication values work here.