app/dev teams get access on the Log Analytics, they access it through the Log Analytics workspace resource in the poral – I believe this is what the article refers as to workspace-context (they have access to the LAW, they can access all data in all tables in that workspace)" - Yes, you are right. If you have granted read access to end users to this "LA Workspace" (workspace-context), then they would have access to all the data stored in this workspace.
Therefore, the target of diagnostic logs will be the "Log Analytics workspace" parameter as chosen when assigning the Policy, i.e., all app gateways forward logs to same workspace. as of today all App Gateways are sitting in one resource group, meaning that when app/dev teams want to access the logs, they get to potentially view logs for others as well (different teams, countries etc.)." - Yes, because you are most probably assigning the policy at Resource Group or Subscription level. This should also help clarify some of the queries that you may have. I am also adding some comments based on your questions/statements in your question. But how would they be able to access to Log Analytics in first place without having RBAC on it …? Accessing the logs through Log Analytics à Logs is referred as to Workspace-context access mode, so you NEED RBAC on the Log Analytics, and then ONLY the workspace permissions apply.Ĭould someone please clarify, am I correct in my assumption, thank you for your questions. Users will have access to data for all resources they have access to.” is listed out …. However, in the table under “How can a user access logs?” under Resource-context “Select Logs from Log Analytics workspaces.
Quoting “ Resource-context: When you access the workspace for a particular resource, resource group, or subscription, such as when you select Logs from a resource menu in the Azure portal, you can view logs for only resources in all tables that you have access to.” But there’s some nonconsistency in the wording IMHO in that article. Looking at the table in the article they would require RBAC only at the resource level (AGW in this case), they wouldn’t require access to the workspace. I was thinking about removing their RBAC from the Log Analytics and just let them access the logs what the article describes as resource-context access mode. Right now, app/dev teams get access on the Log Analytics, they access it through the Log Analytics workspace resource in the poral – I believe this is what the article refers as to workspace-context (they have access to the LAW, they can access all data in all tables in that workspace). I could split all the App Gateways into separate resource groups and assign individual copies of that policy with settings configured to point to different Log Analytics workspaces but this seams to be a more troublesome process. BUT, as of today all App Gateways are sitting in one resource group, meaning that when app/dev teams want to access the logs, they get to potentially view logs for others as well (different teams, countries etc.). However, I’m planning to use the following policy definition provided by the Azure Enterprise Scale project I’ve imported it, tested, works. Occasionally, App Gateways are created without the diagnostic settings enabled on them. We are deploying all our App Gateways in the hub subscription (a hub and spoke architecture). Reading about and how this could potentially solve my problem.
0 kommentar(er)
