Share via

Officially document + support RBAC assignments scoped to secrets that don't exist

Alek Ivankovic 0 Reputation points
2025-11-06T12:20:05.3466667+00:00

I'm a big fan of scoping rbac assignments to secrets for shared key vautlts where multiple apps and identities require access to specific secrets.

What I discovered recently is I can create role assignments scoped to secret's that don't exist yet.

You heard that right! It's also extremely beneficial. Why?

It allows me to separate secrets access control from ownership of the secret.

This is incredibly useful when you consider automation and workloads that perform secret rotations, even more so if terraform is being used.

Why

You may be confused, if this is supported, why am I here asking for official support and documentation?

I wouldn't want to start using this pattern across my organisation, and then find this is no longer supported and suddenly break things.

My question is: Can I most humbly ask for this behaviour to be officially endorsed and documented.

My argument is: Configuring secret access is a seprate concern to secret 'ownership' (aka who declares it in declarative IaC). Documenting this would open up this possibility.

I'd prefer my apps infra to declare role assignments to my sample-client-secret secret, whilst being ignorant to the actual existence of the secret - as other workloads will create/rotate the secret.

This is supported in AWS and documented: https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_iam-policies.html

Azure Key Vault
Azure Key Vault
An Azure service that is used to manage and protect cryptographic keys and other secrets used by cloud apps and services.
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Vinodh247 40,031 Reputation points MVP Volunteer Moderator
    2025-11-08T16:42:50.91+00:00
    1. Yes, you can assign a role scoped to a secret (once the secret exists) in KeyVault; that is supported.
    2. No, there is no official ms documentation or endorsement that this works for future/nonexistent secret names, at least none publicly visible today.
    3. Therefore, your decision to use this pattern broadly across your organisation carries some risk (that ms may change behaviour or silently stop supporting it).
    4. If you choose to adopt it, you should treat it as an internal “supported by us” pattern with monitoring and fallback, not as a fully supported platform guarantee.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.