How are you supposed to prevent the RootManageSharedAccessKey from being used?

[tkent]

We are looking at using Azure Service Bus and quickly noticed that a RootManageSharedAccessKey is created for each service bus namespace and cannot be deleted or disabled.

Using shared credentials of any type violates the common security requirements you see in PCI (PCI-DSS 8.5) and HIPPA § 164.312(a). Most security compliance programs require that identity based access be used for all principals (users or machines) and the use of shared credentials is either very discouraged or expressly forbidden.

Since this key has been described by Microsoft as a master key for the namespace, and we can't remove it, we'd really like to have a coherent story around how we prevent this key from being used.

That's tricky because appears that anyone with read access to the namespace can view this key. The only related issue I've found so far was #51158 and the reply there only indicates that the key should be copied into Azure KeyVault for distribution and that developers should opt to use managed identities. That neither addresses securing the reading of the key in the namespace nor covers preventing its use.

So, what is the story around preventing this key we don't want from being used? The best process I've been able to come up with to-date is:

1. Place the servicebus namespace in a dedicated resource group, with limited access (reduces, but does not remove the problem)
2. Rotate the key automatically frequently (again, reduces, but does not remove the problem)
3. Setup an azure monitor to notify us if the shared keys are ever used (only notifies us after a problem)

...And that's a really bad story. I assume there is a better way to do it, but, what is it? I could find no documentation that covers this topic.

Document Details

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

• ID: 1db9116e-3b52-6b12-3de0-df30c02cd4bb
• Version Independent ID: 45d2a29c-f5f2-6908-1db6-1a7c161bc04f
• Content: Configure your own key for encrypting Azure Service Bus data at rest - Azure Service Bus
• Content Source: articles/service-bus-messaging/configure-customer-managed-key.md
• Service: service-bus-messaging
• GitHub Login: @spelluru
• Microsoft Alias: spelluru

[AjayKumar-MSFT]

@tkent, Thanks for leveraging Azure docs feedback channel to raise this question. Apologies for any inconvenience!

This channel is reserved for ‘Azure docs’ feedback- for sharing doc feedback and suggesting content improvements.

I understand you have mentioned that there is no doc on this scenario/topic, would this feedback be applicable to this doc Create a Service Bus namespace using the Azure portal?

[tkent]

@AjayKumar-MSFT It would probably go as a new page under the "Security" section in the TOC for those docs.

[AjayKumar-MSFT]

@tkent, Thanks for additional details. - We are taking a look into this and will get back to you soon.

[spelluru]

@tkent - I will forward the feedback to the product team so that they can evaluate restricting access to the access key in the Azure portal. Thanks.

"anyone with read access to the namespace can view this key. "

[tspearconquest]

We also have an interest in securing this key so that we can restrict or outright prevent its use.

[spelluru]

You restrict access to the namespace using the following methods right now:

Restrict access to specific IP addresses: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-ip-filtering

Restrict access to specific virtual networks: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-service-endpoints

and also allow access via private endpoints https://docs.microsoft.com/en-us/azure/service-bus-messaging/private-link-service

IMPORTANT: these features are available with only the PREMIUM tier of Service Bus

[tspearconquest]

Unfortunately those methods are network based, what we are looking to do is prevent unauthorized use of the key by insider threats.

[spelluru]

@tspearconquest - ok.

Let me understand clearly. This is the problem, right? We also need to think about accessing it via PowerShell, CLI, or programmatically.

"anyone with read access to the namespace can view this key. "

If you set up the networking rules, you can restrict who can access the namespace even though they know the key (for premium tier only).

I can pass on the information to the product team. You can also submit this feedback and create a feature update request on this page: https://feedback.azure.com/d365community/forum/7c0a897d-2125-ec11-b6e6-000d3a4f0f84.

Thanks.

[tkent]

I'd like to reiterate @tspearconquest's concern about using network source location. While that can be part of a "defense in depth" strategy, even then its pretty poor control. And, apparently, it's only available for the premium tier anyway.

That aside, @spelluru I wanted to ask two things the options you listed in connection with this issue:

• What about RBAC?
• What impact does preventing access to the namespace have? For example, what could you be expected to do with a queue or topic if you did not have access to the namespace?

[spelluru]

For #1, do you mean, we could have a role like "Service Bus Key Reader", and show the key only if the user is a member of this role?

https://docs.microsoft.com/en-us/azure/service-bus-messaging/authenticate-application#azure-built-in-roles-for-azure-service-bus

For #2: without access to the namespace, nothing can be done with the queue or topic.

[tkent]

For #2: without access to the namespace, nothing can be done with the queue or topic.

(record scratch) - That means that every single user or service that interacts with any topic or queue necessarily has access to the RootManageSharedAccessKey. That's gonna be a rough one to explain to auditor if one is savvy enough to put that together. I'm struggling to be believe that's true.

For #1, do you mean, we could have a role like "Service Bus Key Reader", and show the key only if the user is a member of this role?

I was more asking for what already exists, less of what could exist.

[spelluru]

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas#generate-a-shared-access-signature-token

You can provide the sender with the SAS token with limited access instead of giving the access key, which gives them the full access.

[tkent]

@spelluru Ah. Unfortunately, that brings us back to using shared/fixed credentials (SAS = Shared Access Signatures), which is the problem with the RootManageSharedAccessKey. Using SAS is such an incomplete security control that the existing docs have a whole series of warnings like this:

If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your Service Bus resources.

and

Sometimes the risks associated with a particular operation against your Event Hubs outweigh the benefits of SAS.

I'm hoping there is a story around securing the RootManageSharedAccessKey that doesn't force the use of another shared key with a near-idenitical similar set of security issues.

[spelluru]

@clemensv - could you please help me with the issue? Thanks.

[tspearconquest]

@tkent Azure AD is an option for this.

https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-azure-active-directory

However, for my team's use case, having a different SAS from the RootManageSharedAccessKey SAS is all that is required, as our consumer doesn't have the ability to communicate with Azure AD. You are right, but SAS tokens are the most viable option for apps that don't have any interaction with Azure AD.

[tkent]

@tspearconquest - Hmmm, we may be thinking about different things (or maybe not).

We are currently providing access to a service bus instance through managed identities with only the Microsoft.ServiceBus/*/queues/read and Microsoft.ServiceBus/*/receive/action scoped to just the specific queue they need to use. I expected (but haven't confirmed) that those identities will not have access to the namespace.

(However, that idea doesn't fit with @spelluru's comment)

without access to the namespace, nothing can be done with the queue or topic.

In any event, our challenge is that identities who may need access to namespace for observability or auditing purposes will also have access to that root key. That more or less makes providing access scoped to a job responsibility impossible.

[spelluru]

@tkent - could you please post this issue to our Q&A forum for better visibility? Thanks. https://docs.microsoft.com/en-us/answers/topics/azure-service-bus.html

[tkent]

@spelluru - this isn't really a Q&A topic. This is a documentation request and I'd rather not lose the important discussion history and timestamps here.

[EldertGrootenboer]

@tkent As you have found, removing or restricting access to the RootManageSharedAccessKey is not supported. There are some workarounds, like rotating it automatically using a Function etc. You can restrict access to the keys for most consumers by restricting the IAM assignments, and this will allow them to work with their corresponding queues, topics, and subscriptions. However, as you mentioned, consumers with access on the namespace will still be able to read this key. I will check with the team to see if there are improvement opportunities here for the future, but for now this is not something we can do.

[tkent]

@EldertGrootenboer I appreciate the direct response. For the moment, it appears customers subject to things like HIPPA or PCI-DSS have the following options:

1. Mitigate the risk themselves (e.g. dedicated namespaces, frequent key rotations using a lambda, network controls, etc).
2. Be a bit hand-wavy when a QSA asks to see how the service bus configurations don't use shared keys and enforce the principal of least privilege.
3. Opt to not to use service bus for anything where shared keys can't be used or the principal of least privilege must be followed.

When a better story is available, can you please update this case?

[PRMerger10]

Only Microsoft employees can close issues or pull requests via commenting in this repo.

[EldertGrootenboer]

@tkent For now we will close this issue, but I will come back and update here once we have more information around this.

please-close

[EldertGrootenboer]

@tkent In addition to my previous comment, it is possible to completely disable the usage of SAS. In this case, even if RootManageSharedAccessKey were to be leaked, they would not be able to use it. This does mean that Azure AD authentication will need to be used, as per our general recommendations.

[tkent]

@EldertGrootenboer - Thanks for the follow up. That is a much better story. Disabling all shared access keys is what we're after.

Unfortunately, it seems that this feature is new enough that the terraform-provider-azurerm doesn't support it just yet (seems the doc was added Feb 1st, maybe the feature was added earlier though?) .

Anyway, I've filed an issue in the hopes they can add it shortly. For now, we'll have to setup some tooling to enforce it.

[Speeddymon]

@tkent could you possibly share the link to the new issue you opened on the azurerm terraform provider side?

[tkent]

@Speeddymon sure, it was terraform-provider-azurerm#15638. And, they implemented it a while back.