Azure authorization: Seamlessly combine Entra ID user credentials and managed identities for development and production workflows

Overview and goals

Azure Entra ID offers multiple options for obtaining access to cloud resources. The most common ones in use at most enterprises are:

• User-based credentials, to manage access for individuals (see our recent blueprint)
• Managed identity-based credentials, which act as a service account not linked to a specific user. These are typically used to deploy production applications.

In Domino, an administrator can choose what type of credentials to assign to a given user/workload, based on the context that the workload is run under. This article will describe a configuration that allows for segregating development and production credentials.

When should you consider using managed identities for production workloads?

• Users are not allowed access to production data/resources during development
• You want to deploy your application with strong security not linked to an individual
• Allow wide-scope permissions for development and narrow scope for deployment

How can you assign cloud credentials to workloads based on their context?

In addition to user-based credentials, already discussed in an earlier post, you can also enable Azure Workload Identity, similar to IAM Roles for Service Accounts (IRSA). This feature allows us to assign a managed identity credential to a workload in Domino. This is particularly relevant for Domino service accounts, which are unable to utilize user based credentials.

Once this is set up, an admin can choose to assign this identity to a user or workload, based on multiple selectors. Some examples are:

• Single identity for all Domino scheduled jobs
• Single identity for all users under a particular organization
• Separate identities for each Domino service account

In practice, this allows admins to decide what cloud resources can be accessed under various Domino contexts. Putting this together with user-based credentials, you can fine-tune the exact cloud credentials available to any workload launched in Domino.

Going back to the three challenges mentioned earlier, here’s how you can solve each using this method:

• Users are not allowed access to production data/resources during development.

• You want to deploy your application with strong security not linked to an individual.

• Allow wide-scope permissions for development and narrow scope for deployment.

Note that the sources here are not limited to Azure cloud; Entra ID can be federated to allow authentication to a variety of sources outside of the Azure ecosystem. This can provide access to on-premises databases like Oracle and SQL Server, object storage like MinIO or API resources managed via Azure APIM. Also, both auth methods discussed here can be used on non-Azure kubernetes clusters (AWS, GCP, on-premises) as well, with some extra configurations.

Please see the Domino Blueprints Github repo link for the implementation details and how to configure each of the three scenarios above within Domino.

Many other options are possible! Reach out to your Domino Professional Services representatives to ask us how to:

• Mix managed identities and user tokens in the same workflow
• Assign identities based on the project’s owning organization
• Enforce the use of service accounts and managed identities for production workloads