BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News AWS Identity and Access Management Gains Tags and Attribute-Based Access Control

AWS Identity and Access Management Gains Tags and Attribute-Based Access Control

This item in japanese

Bookmarks

Amazon Web Services (AWS) recently enabled tags for IAM users and roles to ease the management of IAM resources. Notably, this release also includes the ability to embrace attribute-based access control (ABAC) and match AWS resources with IAM principals dynamically to "simplify permissions management at scale".

AWS Identity and Access Management (IAM) is the primary account-level feature to securely manage fine-grained access control to AWS services and resources. At its core, IAM is supporting a role-based access control (RBAC) paradigm by defining permissions within policies and attaching those to applicable principals (IAM users and roles). In addition, besides supporting both identity- and resource-based policies, IAM has always supported aspects of attribute-based access control (ABAC) via the optional condition policy element and "expressions in which you use condition operators (equal, less than, etc.) to match the condition in the policy against values in the request", such as IP address or time of day. Furthermore, it has already been possible to dynamically control access using tags to those (comparatively few) resource types that support authorization based on tags.

AWS has now added the ability to tag IAM users and roles, which eases management of IAM entities by enabling the delegation of tagging rights and enforcement of tagging schemes, as explained in more detail in an introductory post by Sulay Shah (product manager for IAM). In a subsequent post, Shah then illustrates how this also enables the use of "attribute-based access control (ABAC) to simplify permissions management at scale" via two new condition context keys:

  • aws:PrincipalTag/<key-name> – This global condition key checks that the tag attached to the principal (user or role) making the request matches the specified key name and value.
  • iam:ResourceTag/<key-name> – This IAM condition key checks that the tag attached to the identity resource (user or role) targeted in the request matches the specified key name and value.

A primary use case for the new feature is to grant IAM principals access to AWS resources dynamically based on attributes. This can now be achieved by matching AWS resource tags with principal tags in a condition – the following example permits operating EC2 instances for each team's current and future instances and members, and both instances and members can be moved to another team by adjusting their respective 'team' tag value:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:RebootInstances",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/team": "${aws:PrincipalTag/team}"
        }
      }
    }
  ]
}

 

Another important use case is to allow IAM principals to assume IAM roles dynamically based on attributes. While multi-account usage and centralized policy-based account management via AWS Organizations are becoming more prevalent (previous coverage), up to now it has been a tedious process to securely manage the underlying cross-account IAM roles. It required a repetition of the 'AssumeRole' statement for each new role an IAM principal should be granted access to with the role-specific ARN as target 'Resource'. This can now be achieved by simply targeting all roles via the wildcard operator '*' in favor of basing the desired granular access decisions on matching IAM resource tags in a condition – the following example permits the principal to assume each role for a security audit if and only if the role has an 'audit' tag with a value of 'true':

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "iam:ResourceTag/audit": "true"
        }
      }
    }
  ]
}

 

According to their respective documentation, both Microsoft's Azure Resource Manager and Google's Cloud IAM primarily support RBAC at this point, though Cloud IAM offers conditions via a private beta (previous coverage). A notable exception is Kubernetes, which supports both ABAC and RBAC authorization modules. However, an introductory article on RBAC support in Kubernetes acknowledges ABAC as powerful yet "difficult to manage and understand [...] as implemented in Kubernetes" and recommends RBAC as the preferred approach based on "where the community is focusing their development efforts".

In related news, AWS has recently added APIs to view service last accessed data so that users can automate permission analysis, which previously required a manual inspection via the AWS Management Console. Scenarios that still require dedicated IAM users rather than using identity federation based on IAM roles and temporary security credentials will also benefit from usability improvements for credentials self-management via the 'My Security Credentials' page.

The IAM documentation features a user guide, including dedicated sections about how IAM works, the policy evaluation logic, and supported IAM features by AWS service. Guidance on IAM best practices and AWS tagging strategies is also available. Support is provided via the Identity and Access Management forum. IAM is an account level AWS feature offered at no additional charge.

Rate this Article

Adoption
Style

BT