Attribute-based access control (ABAC) enhances identity and access management by allowing the assignment of specific conditions to authorization requests. These conditions, often referred to as attributes, include tags that can be attached to IAM resources—such as users or roles—as well as to other AWS resources. Understanding and implementing ABAC policies can be challenging, often acting as a stumbling block for security teams, particularly within the control plane of AWS. At scale a number of projects occur in organizations and resources are constantly changing this is the path for less management of policies with defining specific tags as a strategy.
Deciphering the syntax
Roles and access of roles in Amazon Web Services can be defined in the JSON syntax with the following as a provided example.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllActionsSecretsManagerSameProjectSameTeam",
"Effect": "Allow",
"Action": "secretsmanager:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"access-project",
"access-team",
"cost-center",
"Name",
"OwnedBy"
]
},
"StringEqualsIfExists": {
"aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
"aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
"aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
}
}
}This syntax represents the following notably we can AllActionsSecretsManagerSameProjectSameTeam as a starting point is defined with “Allow” the actions are represented as secretsmanager:* the (*) wildcard allow all actions within that resource secrets manager. Next we can break down the conditions of this searches for tags on resources access-project, access-team, cost-center. In this context we have to have the corresponding tags match a user or role. We define the string equal if exists as the request tag has to match a variable aws:PrincipalTag/<tag>. This allows us to granularly check against the tags being present on the resource. Then in our last portion we have the stringequalifexists states the tags in our defined access-project, access-team, and cost-center must be present and match those on the principal.
Of course we’d want this more defined with passing in some of the following to restrict some operations that we don’t want to occur.
{
"Sid": "AllResourcesSecretsManagerNoTags",
"Effect": "Allow",
"Action": [
"secretsmanager:GetRandomPassword",
"secretsmanager:ListSecrets"
],
"Resource": "*"
},
{
"Sid": "ReadSecretsManagerSameTeam",
"Effect": "Allow",
"Action": [
"secretsmanager:Describe*",
"secretsmanager:Get*",
"secretsmanager:List*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
}
}
},
{
"Sid": "DenyUntagSecretsManagerReservedTags",
"Effect": "Deny",
"Action": "secretsmanager:UntagResource",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "access-*"
}
}
},
{
"Sid": "DenyPermissionsManagement",
"Effect": "Deny",
"Action": "secretsmanager:*Policy",
"Resource": "*"
}
]
}So if you can see a pattern we are defining based on the sid “description of the access” then for the effect (action – Deny) along with the resource its the actions of secretsmanager:*Policy, with resource (*) wildcard this is denial of access to create, edit, or delete Secrets Manager resource-based policies. If the condition wasn’t in place these policies could be used to change the permissions of the secret. Its also important to note a caution approach is to follow best practices and use explicitly denies only when there is no circumstance that should allow that action. This is to exercise the use of white-listing your intended individuals of action and not explicitly block outright as the undefined individuals will be blocked by default.
Getting practice further
If this is a topic you’re trying to understand this further you’re in luck because documentation appears to be rock solid on step by step scenarios on the attribute-based-access policies and I’d recommend diving further into this. You’ll want the path of least resistance and use of pre-defined roles as AWS has countless support on updating services API actions that change throughout the software lifecycle. However, it’s important to note that custom roles while more overhead at least in my view have been the most notable way to limit the control plane access. The smaller amount of permissions assigned along with noted conditions should be exercised with well documented patterns. https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html
Summary
Depending on which hyperscaler you choose you’ll have to understand fundamentally the foundations of access are rooted in the authentication and authorization with authorization playing a larger role due to the use of abstractions that affect our infrastructure. Diving further into AWS Identity and Access Management after Solutions Architect Professional gave me a larger perspective on the use of attribute based access control and patterns for larger enterprises. Dynamic tags are also used in Entra ID and I can see how the implementation of ABAC can coincide for those users residing with AWS.