I am trying to setup narrow down the best possible role for monitoring data from security perspective. My needs are slightly different so I don't want to use the Security Reader role (mainly because security reader only has access to the security center items and basic resource and resource group queries). So after reading more I stumbled upon Monitoring Reader role and just Reader role. I went through the permissions mentioned in the JSON. However I am not sure if all the differences are covered in the JSON.
For instance when we talk about "Monitoring Reader"
{
"assignableScopes": [
"/"
],
"description": "Can read all monitoring data.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"name": "43d0d8ad-25c7-4714-9337-8ba259a9fe05",
"permissions": [
{
"actions": [
"*/read",
"Microsoft.OperationalInsights/workspaces/search/action",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Monitoring Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
The privileges are basically the same expect that I can query the logs. Compared to the Reader role which is
{
"assignableScopes": [
"/"
],
"description": "Lets you view everything, but not make any changes.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
"name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
"permissions": [
{
"actions": [
"*/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs? If not, how is it different? Also which role is superior in terms of access to readable data?
Reference : https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#reader
PS : I do know about custom roles but want to understand built-in roles better.
Now from a logical standpoint if both the users are able to execute */read doesn't Reader role automatically qualify to query the logs?
They are both able to execute */read, but Reader cannot query the logs.
If not, how is it different?
The difference is Monitoring Reader can execute the Microsoft.OperationalInsights/workspaces/search/action and Microsoft.Support/* actions.
Also which role is superior in terms of access to readable data?
From the actions scope of the role definition, obviously the Monitoring Reader is superior in terms of access to readable data.
Related
I have user and group provisioning set up for an enterprise application in Azure AD. I have a SCIM endpoint setup in my application to consume the SCIM requests from Azure AD. I added this feature flag to my tenant URL to ensure SCIM compliance: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/application-provisioning-config-problem-scim-compatibility#flags-to-alter-the-scim-behavior
I have a group assigned to the enterprise application for provisioning to my application. When I add users to that group in Azure AD, I'm seeing two PATCH requests to the Groups/:id SCIM endpoint. The first is an add operation, which I expect because I'm adding this user as a member of the group:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "add",
"path": "members",
"value": [
{
"value": "directory_user_01F7SGPZHKVGHZMCRNHGJXW1E9"
}
]
}
]
}
The second PATCH request is a replace operation, which is unexpected as I'm not replacing all users in a group with the one member being added:
{
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"
],
"Operations": [
{
"op": "replace",
"path": "members",
"value": [
{
"value": "directory_user_01F7SGPZHKVGHZMCRNHGJXW1E9"
}
]
}
]
}
The SCIM protocol RFC outlines the difference between the add and replace operations in PATCH requests. If users are added as members of a group, there should only be an add operation, not a replace operation. Is there any way to configure Azure so it only sends add operations in this situation? Thanks!
I have a CosmosDB in Azure, I want to give a user access to read the data inside various collections.
I tried giving them the 'Reader'-role, it let them se that there existed a CosmosDB, and they could see some meta data. But they were unable to access the data within
I assigned them the 'Cosmos DB Account Reader' and this had better results.
But it seems to me that the 'Reader' role should superseed the 'Cosmos DB Account Reader' role. Or am i on the wrong track here? I beleived that the 'Reader'-role gave *all read access.
EDIT:
There seems to be no issue using the built in 'Data Explorer' on portal.azure.com.
The real issue is on using cosmos.azure.com, and logging inn using ActiveDirectory, did not let the user see anything with the 'Cosmos DB Account Reader'-role. Might be it requires a user has write-access.
In order to read the data from Cosmos DB accounts, a user should be in a role that allows fetching access keys. A Reader role does not have this capability. However
Cosmos DB Account Reader role has the capability to fetch the read-only access keys using which a user in this role can read the data (but not make any changes to that data).
From this link, here's the definition of Cosmos DB Account Reader role:
{
"assignableScopes": [
"/"
],
"description": "Can read Azure Cosmos DB Accounts data",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/fbdf93bf-df7d-467e-a4d2-9458aa1360c8",
"name": "fbdf93bf-df7d-467e-a4d2-9458aa1360c8",
"permissions": [
{
"actions": [
"Microsoft.Authorization/*/read",
"Microsoft.DocumentDB/*/read",
"Microsoft.DocumentDB/databaseAccounts/readonlykeys/action",
"Microsoft.Insights/MetricDefinitions/read",
"Microsoft.Insights/Metrics/read",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Support/*"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
"roleName": "Cosmos DB Account Reader Role",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
Microsoft.DocumentDB/databaseAccounts/readonlykeys/action action enables getting read-only access keys and thus read the data.
I am trying to create a custom role in Azure that would allow Subscriptions "owners" to do quite everything but cancelling/renaming their own subscriptions or moving into another management group.
I would also like them to be able to grant right access to who they want (especially built-in "Contributor" role) but without allowing them to grant "Owner" right, otherwise my custom role could be tricked easily.
I ended up with the following custom role definition which is so far nice and working, apart from the role assignment of course:
{
"Name": "MyCustomRole",
"IsCustom": true,
"Description": "Role designed for Azure subscriptions ownership limitations",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Management/managementGroups/subscriptions/write",
"Microsoft.Subscription/cancel/action",
"Microsoft.Subscription/rename/action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/providers/Microsoft.Management/managementGroups/root.mg"
]
}
In the Azure documentation, the only operation I found for role assignment is Microsoft.Authorization/roleAssignments/write.
Is there any way to restrict that - to Contributor role assignment for instance - directly in the custom role?
Azure Policy might technically do the trick (not even sure), but since some operational/experts/whatever guys might end up as Owner, I do not want the policy engine to display "non-compliant" resources. It would lead customers to misunderstandings that I would like to avoid.
You might want to try Azure Policy, which you can apply on top of your IAM model. You can assign a policy on the Subscription or Management Group level, based on your governance structure.
Policy definition below will block EVERY request trying to assign "Owner" role with no exception. Built-in Owner role is represented by "8e3af657-a8ff-443c-a75c-2fe8c4bcb635", same GUID across all Azure tenants.
However Role assignments of other RBAC roles would still be possible. This should fullfill your use case.
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
{
"policyType": "Custom",
"mode": "All",
"displayName": "DenyOwnerAssisgnment",
"policyRule": {
"if": {
"allOf": [
{
"field": "Microsoft.Authorization/roleAssignments/roleDefinitionId",
"contains": "8e3af657-a8ff-443c-a75c-2fe8c4bcb635"
},
{
"field": "type",
"equals": "Microsoft.Authorization/roleAssignments"
}
]
},
"then": {
"effect": "deny"
}
},
"type": "Microsoft.Authorization/policyDefinitions"
}
To my knowledge - no, you cannot be granular. you can only restrict a specific action.
ps. technically this is correct. but the policy usage above is really clever ;)
Yes it should be possible when you assign a policy, so it's not part of the definition but assignment. You can assign policy on the subscription-level scope, and exclude resource groups. You can do that via "notScopes".
Please see Azure Policy docs for how to do this (chapter Excluded scopes)
The scope of the assignment includes all child resource containers and
child resources. If a child resource container or child resource
shouldn't have the definition applied, each can be excluded from
evaluation by setting notScopes. This property is an array to enable
excluding one or more resource containers or resources from
evaluation. notScopes can be added or updated after creation of the
initial assignment.
https://learn.microsoft.com/en-us/azure/governance/policy/concepts/assignment-structure
You can include excluded scopes in the portal when assigning Policy or through PowerShell by including -NotScope parameter.
I'm designing a solution for an ERP requirement. The Client insists on using AAD for one point management of users for different applications.
Since AAD has the capability of rendering Oauth service, I'm intending to use it as my OAUTH server and utilize its tokens inside my WebAPI services. But was wondering how I can capture the failed user login attempts as I need to apply locking mechanism.
When I found that AAD can handle this locking mechanism also through some configurations, I'm now left out with a question whether I can just use AAD for my user store, meaning I will have the users, their credentials and their roles stored in AAD, while I will have the permissions for each role and other data stored in my application's database.
Is this a feasible solution? or is there a different way of handling this?
Note: We are using noSQL database.
Yes, this is a feasible solution. You can use application roles to assign roles to users.
You can define the application roles by adding them to the application manifest. Then you can assign these roles to a user.
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "Creators can create Surveys",
"displayName": "SurveyCreator",
"id": "1b4f816e-5eaf-48b9-8613-7923830595ad",
"isEnabled": true,
"value": "SurveyCreator"
},
{
"allowedMemberTypes": [
"User"
],
"description": "Administrators can manage the Surveys in their tenant",
"displayName": "SurveyAdmin",
"id": "c20e145e-5459-4a6c-a074-b942bbd4cfe1",
"isEnabled": true,
"value": "SurveyAdmin"
}
],
The user list with roles listed.
I am currently helping investigate adopting Azure for my organization's public cloud. One of the tasks I have been assigned is locking down accounts to prevent users from being able to elevate their permissions within a subscription.
One of the things in particular I am interested in is denying the creation of Custom Roles, as we don't want people to go and start creating their own roles until the need for the role has been vetted by security.
I have been trying to do this via an Azure policy with the following definition
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Authorization/roleDefinitions"
},
{
"field": "Microsoft.Authorization/roleDefinitions/type",
"equals": "CustomRole"
}
]
},
"then": {
"effect": "Deny"
}
}
It was actually just the built in "Audit Custom Roles" policy copied over and changing the effect from "Audit" to "Deny"
However I have applied this policy to the Management Group that contains the subscription I am testing with, and yet when I login to the CLI and try and create a new custom role it goes ahead and creates the role.
I have ensured that the policy is present on the subscription, and I have confirmed that I am in the correct subscription in the CLI (using az account show) yet I am still allowed to create custom roles.
Is this just not something Azure supports, or is there something else I am missing? Any help or guidance would be greatly appreciated as the Microsoft docs and the numerous examples available online don't seem to have any information on controlling roles with policies.
P.S.
I know that you can control roles to some extent through policies as we have another policy that prevents the assignment of a certain set of roles from happening and that does work.
It looks like Azure CLI creates the role definition without populating the "type" field. The following policy will handle this:
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Authorization/roleDefinitions"
},
{
"anyOf": [
{
"field": "Microsoft.Authorization/roleDefinitions/type",
"equals": "CustomRole"
},
{
"field": "Microsoft.Authorization/roleDefinitions/type",
"exists": "false"
}
]
}
]
},
"then": {
"effect": "Deny"
}
}