search

MicrosoftDocs / azure-docs

Open source documentation of Microsoft Azure
https://docs.microsoft.com/azure
Creative Commons Attribution 4.0 International
10.25k stars 21.42k forks source link

Guidance on sharing of individual secrets is unclear. #120360

Closed markshyn closed 7 months ago

markshyn commented 7 months ago

Near the beginning of the article, the statement is made that "Individual keys, secrets, and certificates permissions should be used only for specific scenarios." After that statement, there is a bullet item which states: "Sharing individual secrets between multiple applications, for example, one application needs to access data from the other application". It's not entirely clear what is being said here. It sounds like you're giving an example of a scenario where it makes sense to use a secret that is shared across applications, but that this represents an exception to the general guidance that it's best to avoid sharing secrets across applications. Is that the correct interpretation? If so, may I suggest replacing the sentence and the bullet item with a statement similar to the following:

Sharing of a secrets (or keys or certificates) across multiple applications is best avoided. Exceptions to this general guidance do exist, however, such as when one application needs to access data from another application.

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

RamanathanChinnappan-MSFT commented 7 months ago

@markshyn Thanks for your feedback! We will investigate and update as appropriate.

jlichwa commented 7 months ago

Hello @markshyn the statement what we tried to say that you should never use per secret permissions:

"Individual keys, secrets, and certificates permissions should be used only for specific scenarios:"

And then we provide exceptional scenario:

Would below statement describe it better:

Assigning roles on individual keys, secrets and certificates should be avoided. Exceptions to general guidance:

markshyn commented 7 months ago

Hi Jack,

OK, I’m still puzzled. On the one hand, there are these statements near the beginning of the article:

Azure role-based access control (Azure RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources.

. . .

The Azure RBAC model allows uses to set permissions on different scope levels: management group, subscription, resource group, or individual resources. Azure RBAC for key vault also allows users to have separate permissions on individual keys, secrets, and certificates.

Those two sentences make it sound like it is possible and perfectly reasonable to set permissions on individual keys, secrets, and certificates using the RBAC model.

But then the section that follows, titled Best Practices for individual keys, secrets, and certificates role assignments makes it sound like it is not recommended (except in very specific scenarios) to assign roles that target a specific key (or specific secret or specific certificate). That seems strange to me. Are you saying that when you assign the role granting access, the access scope should be the entire key vault? Wouldn’t it often happen that you want to assign a role that applies to only one of the keys in the vault and not all the keys? For example, suppose I’m storing secrets alpha, beta, and gamma in the vault. And suppose that applicationA need to read secret alpha, applicationB reads secret beta, and applicationC reads secret gamma. So when I grant the appropriate role to applicationA, I want to grant it access to just secret alpha but NOT to secret beta or gamma. So I wouldn’t want the roles I’m assigning to apply to the entire key vault.

The ability to grant fine-grained access control is supposed to be a benefit of RBAC is it not? Then why would this be discouraged?

Mark

From: Jack Lichwa @.> Sent: Friday, March 1, 2024 7:45 PM To: MicrosoftDocs/azure-docs @.> Cc: Mark S. @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Guidance on sharing of individual secrets is unclear. (Issue #120360)

Hello @markshyn https://github.com/markshyn the statement what we tried to say that you should never use per secret permissions:

"Individual keys, secrets, and certificates permissions should be used only for specific scenarios:"

And then we provide exceptional scenario:

Would below statement describe it better:

Assigning roles on individual keys, secrets and certificates should be avoided. Exceptions to general guidance:

— Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/azure-docs/issues/120360#issuecomment-1974138749 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2WKTUZGBLGA74LEUP36VDYWEOITAVCNFSM6AAAAABEB3ZDDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGEZTQNZUHE . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AC2WKTU7IMWK7BWU42QALN3YWEOITA5CNFSM6AAAAABEB3ZDDWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTVVL3X2.gif Message ID: @. @.> >

markshyn commented 7 months ago

Oh, okay, I think I overlooked the very first sentence in the article:

Our recommendation is to use a vault per application per environment (Development, Pre-Production, and Production).

So if you create a separate vault for every distinct { application, environment } combination, then you’re assuming that a given application will want to be granted the same set of permissions to all the keys in the vault. Perhaps that’s a reasonable assumption, but I’m not totally that’s flexible enough.

Wow, this really gives me pause. So if I have a couple dozen applications, then I’m going to have to create a couple dozen key vaults for each environment. For real? This doesn’t sound terribly practical.

Why not simply say that it’s perfectly fine to grant RBAC roles at the finest granularity, i.e. at the key/secret/certificate level. That way I don’t need to create so many key vaults.

So this guidance seems to favor creating a ton of key vaults in order to avoid very fine-grained role assignments. Perhaps there’s a good argument for going that route … but it really seems strange to me.

Mark

From: Jack Lichwa @.> Sent: Friday, March 1, 2024 7:45 PM To: MicrosoftDocs/azure-docs @.> Cc: Mark S. @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Guidance on sharing of individual secrets is unclear. (Issue #120360)

Hello @markshyn https://github.com/markshyn the statement what we tried to say that you should never use per secret permissions:

"Individual keys, secrets, and certificates permissions should be used only for specific scenarios:"

And then we provide exceptional scenario:

Would below statement describe it better:

Assigning roles on individual keys, secrets and certificates should be avoided. Exceptions to general guidance:

— Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/azure-docs/issues/120360#issuecomment-1974138749 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2WKTUZGBLGA74LEUP36VDYWEOITAVCNFSM6AAAAABEB3ZDDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGEZTQNZUHE . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AC2WKTU7IMWK7BWU42QALN3YWEOITA5CNFSM6AAAAABEB3ZDDWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTVVL3X2.gif Message ID: @. @.> >

markshyn commented 7 months ago

I accidentally left out a word in my prior email message, so I’m adding the missing word (and highlighting it in green) and re-sending the message:

Oh, okay, I think I overlooked the very first sentence in the article:

Our recommendation is to use a vault per application per environment (Development, Pre-Production, and Production).

So if you create a separate vault for every distinct { application, environment } combination, then you’re assuming that a given application will want to be granted the same set of permissions to all the keys in the vault. Perhaps that’s a reasonable assumption, but I’m not totally convinced that’s flexible enough.

Wow, this really gives me pause. So if I have a couple dozen applications, then I’m going to have to create a couple dozen key vaults for each environment. For real? This doesn’t sound terribly practical.

Why not simply say that it’s perfectly fine to grant RBAC roles at the finest granularity, i.e. at the key/secret/certificate level. That way I don’t need to create so many key vaults.

So this guidance seems to favor creating a ton of key vaults in order to avoid very fine-grained role assignments. Perhaps there’s a good argument for going that route … but it really seems strange to me.

Mark

From: Jack Lichwa @.> Sent: Friday, March 1, 2024 7:45 PM To: MicrosoftDocs/azure-docs @.> Cc: Mark S. @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Guidance on sharing of individual secrets is unclear. (Issue #120360)

Hello @markshyn https://github.com/markshyn the statement what we tried to say that you should never use per secret permissions:

"Individual keys, secrets, and certificates permissions should be used only for specific scenarios:"

And then we provide exceptional scenario:

Would below statement describe it better:

Assigning roles on individual keys, secrets and certificates should be avoided. Exceptions to general guidance:

— Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/azure-docs/issues/120360#issuecomment-1974138749 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2WKTUZGBLGA74LEUP36VDYWEOITAVCNFSM6AAAAABEB3ZDDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGEZTQNZUHE . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AC2WKTU7IMWK7BWU42QALN3YWEOITA5CNFSM6AAAAABEB3ZDDWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTVVL3X2.gif Message ID: @. @.> >

jlichwa commented 7 months ago

It is RBAC definition from Azure RBAC documentation :

https://learn.microsoft.com/en-us/azure/role-based-access-control/overview If you see in comparison to Storage Account Key, which gives permission to do everything, RBAC has roles to provide access based on various roles.

Yes, this you should go as granular as your deployment unit (atomicity), so it could at workload or even microservice, if it is fully atomic (think microservice with their own storage and can independently deployed). But usual will be application if it is monolithic or group of related services.

Key Vault defines security boundary allowing complete isolation for workload, application on network, identity access, logging etc...

It is recommended to your workloads, application at both network and identity access, so even if identity is compromised it can only be accessed from application/workload resources/network. It also allows teams to work in complete isolation. Same for operators will have limited access scope in case of need to add secret or production issue, with access to limited number of secrets. And that is where Key Vault instance comes to play group closely related secrets.

It is quite common for Secrets Managers (I believe all of them) provide isolation between apps either through namespaces, folders, in Azure it is Key Vault instance/container with hierarchical organization with subscriptions (scale unit), resource groups (apps/workloads). Key Vault provides stronger isolation with network and logging isolation at application level which is not available in many other Secret Managers making them more vulnerable.

Also RBAC per secrets can only be used for reads, for any monitoring, rotation (event grid), adding new secrets operator will need access to entire Key Vault (all secrets) which expose it to high risk.

Provide as granular isolation for your secrets as your deployment, and that way any updates, issues will only affect that workload. Otherwise even bug in workload reading a lot of secrets causing Key Vault to throttle will take down everything using that Key Vault. Hope it helps.

markshyn commented 7 months ago

Thanks for your responses, Jack.

OK, so now that I understand the thinking, if I may, I’d like to suggest a slight re-wording to make this clearer to someone like me who wasn’t familiar with this perspective.

Perhaps something like this:

Our recommendation is to use a vault per application per environment (Development, Pre-Production, and Production), and to assign roles at the vault scope rather than at the certificate/secret/key scope.

or like this:

Our recommendation is to create a separate vault per distinct application/environment combination, and to assign roles at the vault scope rather than at the certificate/secret/key scope.

This guidance does assume that the same set of permissions will be appropriate for all of the keys/secrets/certificates in a given vault (granted they’re for a single application). I honestly don’t know if that’s always true, so that’s another concern I have with this approach, but I will assume that Microsoft has thought about it and doesn’t consider it to be an issue.

No response necessary this time around, Jack. Have a good day.

Mark

From: Jack Lichwa @.> Sent: Saturday, March 2, 2024 12:54 AM To: MicrosoftDocs/azure-docs @.> Cc: Mark S. @.>; Mention @.> Subject: Re: [MicrosoftDocs/azure-docs] Guidance on sharing of individual secrets is unclear. (Issue #120360)

It is RBAC definition from Azure RBAC documentation :

https://learn.microsoft.com/en-us/azure/role-based-access-control/overview If you see in comparison to Storage Account Key, which gives permission to do everything, RBAC has roles to provide access based on various roles.

Yes, this you should go as granular as your deployment unit (atomicity), so it could at workload or even microservice, if it is fully atomic (think microservice with their own storage and can independently deployed). But usual will be application if it is monolithic or group of related services.

Key Vault defines security boundary allowing complete isolation for workload, application on network, identity access, logging etc...

It is recommended to your workloads, application at both network and identity access, so even if identity is compromised it can only be accessed from application/workload resources/network. It also allows teams to work in complete isolation. Same for operators will have limited access scope in case of need to add secret or production issue, with access to limited number of secrets. And that is where Key Vault instance comes to play group closely related secrets.

It is quite common for Secrets Managers (I believe all of them) provide isolation between apps either through namespaces, folders, in Azure it is Key Vault instance/container with hierarchical organization with subscriptions (scale unit), resource groups (apps/workloads).

Hope it helps.

— Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/azure-docs/issues/120360#issuecomment-1974330421 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2WKTVBTT5U7FPEIDXMHBDYWFSPTAVCNFSM6AAAAABEB3ZDDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGMZTANBSGE . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AC2WKTWYUG744ZSJJHVOM4DYWFSPTA5CNFSM6AAAAABEB3ZDDWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTVVXSDK.gif Message ID: @. @.> >

SaibabaBalapur-MSFT commented 7 months ago

@markshyn We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.