Deprecating User-assigned and System-assigned managed identity access modes

[aramase]

Deprecating User-assigned and System-assigned managed identity access modes

The Azure Key Vault provider for Secrets Store CSI Driver offers 5 identity access modes for accessing a Key Vault instance: https://azure.github.io/secrets-store-csi-driver-provider-azure/docs/configurations/identity-access-modes/.

Why the deprecation?

tl;dr: Not secure. Do not use this option

In case of user-assigned and system-assigned managed identity, the identity is manually assigned to the underlying VMSS by running az vmss identity assign. This identity is then accessible by any pod running on the cluster. The only way to control which pod has access to which identity is by using AAD Pod Identity.

AAD Pod Identity only works on Linux and is one of the supported access modes for accessing Key Vault. As mentioned in the announcement, AAD Pod Identity will soon be replaced with Azure Workload Identity.

What should I use?

We recommend using the new Workload Identity mode to access Key Vault. Benefits of workload identity:

1. Supported on both Linux and Windows.
2. Supports Kubernetes clusters hosted in any cloud or on-premises.
3. Easy to set up

What is the deprecation plan?

1. Removing references from the doc for user-assigned and system-assigned managed identity.
2. Delete the code from the provider that removes support for using user-assigned and system-assigned managed identity.

Future identity access modes

• Workload Identity will be blessed mode for accessing the key vault instance in the future.
• Service Principal access mode will also be supported because the credentials are namespaced.
• Support for pod identity will only be removed when AAD Pod Identity is completely replaced with Azure Workload Identity.

This is a placeholder issue to inform all users about the why and how on deprecation. We recommend users to evaluate the more secure options like Workload Identity, Service Principal to access Key Vault.

Note: We will update this issue with more timelines on when the deprecation will happen and support will be removed.

If there are any concerns or questions, please feel free to comment on this issue!

[trhumphries]

What the depreciation date for Managed Identities?

[aramase]

What the depreciation date for Managed Identities?

I'll post an update here when we finalize the release and date.

[github-actions]

This issue is stale because it has been open 14 days with no activity. Please comment or this will be closed in 7 days.

[Xaseron]

@aramase how would you sync a kubernetes pull secret with a workload identity?

[aramase]

@aramase how would you sync a kubernetes pull secret with a workload identity?

@Xaseron Workload identity documentation is here: https://azure.github.io/secrets-store-csi-driver-provider-azure/docs/configurations/identity-access-modes/workload-identity-mode/

[verokarhu]

Looks like AAD-Pod-Identity was deprecated in October 2022:
IMPORTANT: As of Monday 10/24/2022, AAD Pod Identity is deprecated. As mentioned in the [announcement](https://cloudblogs.microsoft.com/opensource/2022/01/18/announcing-azure-active-directory-azure-ad-workload-identity-for-kubernetes/), AAD Pod Identity has been replaced with [Azure Workload Identity](https://azure.github.io/azure-workload-identity). Going forward, we will no longer add new features to this project in favor of Azure Workload Identity. We will continue to provide critical bug fixes until Azure Workload Identity reaches general availability. Following that, we will provide CVE patches until September 2023, at which time the project will be archived.

Can we assume that the same timeline applies to the secrets provider?

[bt701]

I agree with this in concept, however this Azure/azure-workload-identity#373 probably blocks the useability.

Might use case at the moment is to sync imagepull secrets, which are fine to be shared across all namespaces (hence each workload can drop-in the class) and get a synced secret.

There's no clear path around this for federated identities though, perhaps https://github.com/kubernetes-sigs/secrets-store-sync-controller, but then it would be only do-able when this is an addon for AKS.

As workload identities

1. map to a service account (without wildcards)
2. also have a limit of 20 service accounts anyway.

It would be an absolute pain to use them over assigning MIs in this case.

The design I have, is a single keyvault with this read-only credential for the image pull secret to a cluster.

I could probably try ACR caching, and image pull via ACR, but we use Artifactory for our store, and that's not supported either Azure/acr#683