Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AKS outbound traffic requirements for storage and ACR #116239

Closed
dstarkowski opened this issue Oct 20, 2023 · 8 comments
Closed

AKS outbound traffic requirements for storage and ACR #116239

dstarkowski opened this issue Oct 20, 2023 · 8 comments
Assignees
@asudbring
Labels
aks-networking/subsvc assigned-to-author azure-kubernetes-service/svc Pri2 product-question triaged

Comments

@dstarkowski
Copy link

I have configured all the outbound rules as described in the article.
I still see some outbound flows in Azure Firewall logs that were not matched by any of the rules.

First is an Azure Container Registry: inuxgeneva-microsoft.azurecr.io.
This is used by one of the containers in DAPR extension, but the only mention I found of it on the internet is related to ARC (we're using AKS managed cluster).

Then there are 37 storage accounts (where ### are numbers or random strings):

  • 1x neumanaged###.blob.core.windows.net
  • 2x md-############.z##.blob.storage.azure.net
  • 4x wusreplica###.blob.core.windows.net
  • 30x umsa################.blob.core.windows.net

Here's the only mention about storage accounts in the article:

Under certain circumstances, it might happen that traffic towards "md-*.blob.storage.azure.net" is required. This dependency is due to some internal mechanisms of Azure Managed Disks. You might also want to use the Storage service tag.

"Under certain circumstances" and "You might want" are a bit vague when talking about security. Can we get a clarification about the circumstances and what are those accounts used for exactly?

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
@Naveenommi-MSFT
Copy link
Contributor

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

@ManoharLakkoju-MSFT
Copy link
Contributor

@dstarkowski
I'm going to assign this to the document author so they can take a look at it accordingly

@asudbring
Can you please check and add your comments on this doc update request as applicable.

@harinarayanan-muthukumar
Copy link

+1 , Facing the same issue and a more clear document would be highly appretiated . We leverage Azure Native Tools like ACR and even still seeing issues while connecting from AKS Clusters via Azure Firewall . Ideally the container registry tag should cover everything thats needed for the firewall to allow all URLS needed to pull image from ACR

@kamilzzz
Copy link

kamilzzz commented May 9, 2024

Do we have any update?

@rayoef
Copy link
Contributor

rayoef commented Jul 12, 2024

Thank you for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner, and we sincerely apologize for the delayed response. The requested updates have not been made since the creation of this issue, so we've created an internal work item to incorporate your suggestions. We are closing this issue for now, but feel free to comment here as necessary.

#please-close

@dstarkowski
Copy link
Author

@rayoef
Thank you for the update.

Please keep in mind that this issue is not about a typo or something unclear/missing in the documentation, which can wait another 9 months.

This is about SECURITY. It is currently not possible to properly secure the cluster without this information.
Opening firewall rules to allow traffic to ALL storage accounts (which we must do without knowing exact accounts that are required) opens a risk of data exfil through storage accounts. This must be remediated and to do that we need information on specific accounts that are required and what is their purpose.

@psddp
Copy link

psddp commented Aug 13, 2024 •
edited
Loading

Thank you for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner, and we sincerely apologize for the delayed response. The requested updates have not been made since the creation of this issue, so we've created an internal work item to incorporate your suggestions. We are closing this issue for now, but feel free to comment here as necessary.

#please-close

@rayoef We need update on this, I have a major client who could dismiss AKS because of this issue

@rayoef
Copy link
Contributor

rayoef commented Aug 15, 2024

@psddp @dstarkowski My team is working on investigating this issue. I'll circle back when we've updated the text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@asudbring asudbring

Labels
aks-networking/subsvc assigned-to-author azure-kubernetes-service/svc Pri2 product-question triaged
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@psddp @dstarkowski @asudbring @kamilzzz @rayoef @harinarayanan-muthukumar @ManoharLakkoju-MSFT @Naveenommi-MSFT