Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

compose: migrate database to managed identity #4481

Open
weikanglim opened this issue Oct 23, 2024 · 1 comment
Open

compose: migrate database to managed identity #4481

weikanglim opened this issue Oct 23, 2024 · 1 comment
Assignees
@weikanglim
Labels
design
Milestone
Backlog

Comments

@weikanglim
Copy link
Contributor

weikanglim commented Oct 23, 2024 •
edited
Loading

Goal: Migrate all databases to only leverage managed identity by default.

Some overall design considerations:

Token vs. passwords

With managed identity, a key exchange is performed to retrieve a short-lived access token. This is different than traditional database passwords which is a pre-negotiated, long-lived key.

This will introduce challenges in the app code consumption, especially in zero-downtime access scenarios.

Examples

  • Azure Cache for Redis:

    • Ensure that your client application sends a new Microsoft Entra token at least three minutes before token expiry to avoid connection disruption.
    • When you call the Redis server AUTH command periodically, consider adding a random delay so that the AUTH commands are staggered. In this way, your Redis server doesn't receive too many AUTH commands at the same time.

  • Postgres,

    export PGPASSWORD=`curl -s 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fossrdbms-aad.database.windows.net&client_id=CLIENT_ID' -H Metadata:true | jq -r .access_token`

psql -h SERVER --user USER DBNAME

    This password would expire after some time.

  • MySql:

    The access token validity is anywhere between 5 minutes to 60 minutes. We recommend you get the access token before initiating the sign-in to Azure Database for MySQL flexible server.

  • Cosmos:

    The user is unable to use the existing MongoDB / NoSQL libraries. They must now import CosmosClient and connect to the client. They wouldn't be able, for example, directly use a MongoDB client. It breaks the technology abstraction.

Deployment scripts required

Certain database resource providers require a direct connection to the database to provision Entra objects enabled for Managed identity. This means that an ad-hoc script/operation is required. If we want a fully managed experience, this feature will then depend on operations / scripts as a pre-requisite.

Examples

  • For Postgres, the following execution statement is required:

    select * from pgaadauth_create_principal('<identity_name>', false, false);

  • For MySql,

    CREATE AADUSER '[email protected]';

Keyless vs. Key-based connection

We will likely have to support key-based connections. This is especially important when using existing Azure resources. In these cases, the app developer will not be able to grant themselves permissions to the database.

The important consideration here:

Managed identity is configured on the database server. If the database server isn't fully exposed in configuration, how would a user describe this gesture?
@weikanglim weikanglim added this to the Backlog milestone Oct 23, 2024
@weikanglim weikanglim self-assigned this Oct 23, 2024
@weikanglim weikanglim mentioned this issue Oct 23, 2024
Merged
@seesharprun
Copy link

seesharprun commented Oct 24, 2024 •
edited
Loading

@weikanglim

Here's some guidance for Azure Cosmos DB:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@weikanglim weikanglim

Labels
design
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
2 participants
@weikanglim @seesharprun