Role, Attribute, and Policy Based Access Control simplify IAM at scale using the most fine-trained way access in AWS, Azure, Kubernetes, and other systems
RBAC, ABAC, and PBAC are NOT service offerings from any one cloud vendor, but design approaches to Access Control. So there are differences in how to operate under each approach in AWS vs Azure vs Kubernetes, etc.
NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.
If you’re working in a large enterprise, you need a way to meet GRC (Governance, Risk management, and Compliance) requirements in a way that is also more secure and scalable.
As an organization increases in size, it becomes increasingly difficult for overseers of IT management accounts who operate away from the day-to-day technical teams and business managers. When “out of the loop”, administrators need to “rubber stamp” key authorization requests. The larger the organization, the greater distance between those in leadership roles and those in IT. And business leaders become more dependent on the IT department.
PROTIP: One innovative approach is to enable business leaders to participate in security configurations by providing them an easy way to specify rules about access. That’s called PBAC (Policy-Based Access Control) – the result of a progression from RBAC and ABAC.
“Role Explosion” in “Traditional” RBAC
Enterprise IAM managers and architects who manage thousands of roles controlling access to hundreds of users.
Do they face “role explosion” toil?
VIDEO: Traditional RBAC is problematic at scale when each team has similar (but different) resources such that Role Assertions and Policy Sets are established for each team which are near identical except for resource identifiers.
There are four levels of role-based access control that can be implemented:
Flat RBAC – All users and permissions are assigned roles. A user must take on a role to obtain the permissions needed. As a consequence, a user can be assigned multiple roles to have multiple permissions. Roles can be assigned to multiple users.
Hierarchical RBAC – Adds a hierarchy to the role structure that sets out relationships between roles. Higher seniority roles acquire the permissions of junior roles.
Constrained RBAC – Adds a separation of duties so that multiple users must complete a single task to ensure that no malicious changes can be made to your system.
Symmetric RBAC – Permissions associated with each role are reviewed periodically. An administrator can pull permissions from one user and then reassign them to another individual.
Less Toil with ABAC?
ABAC grants access is based on matching attributes (tags) associated with each user.
The transiton from RBAC to ABAC is the rare case where administration after scaling and improving security is less work than before. It’s actually less toil to onboard users and groups to ABAC or PBAC (Policy-Based Access Control)
It takes a bit of work to transition away from RBAC (Role-Based Access Control). So if you’re starting out small on AWS, using ABAC from or PBAC the beginning would be a wise move.
With ABAC, only one set of Role Assertions and Policies is defined to control several similar teams. Each resource is tagged (red or blue in the diagram) to designate ownership and access by a team (rather than updating Policies).
The ABAC approach saves time and increases security at the same time because permissions for each user is a on-going dynamic situation, so automated Context Rule Triggers would reduce manual toil (and mistakes) throughout the lifecycle of joiners, movers, and leavers:
VIDEO: With ABAC, Polices apply across all projects, including projects which don’t yet exist. For example, they can create an Attribute-based Policy where access is granted only when values of the attributes for both subject and object have an identitcal match. This single Project ensures that only the users assigned to the Project can get access to files of that project. Another policy can be established so only auditors get access to sensistive financial data.
Concerns about ABAC & XACML
A. The dynamic nature of ABAC makes it more difficult for security and regulatory compliance auditing. While auditors of RBAC can just look at privileges each user has been assigned, ABAC you’re rarely able to look up users and see what they have permission to access, as you’d have to check each object against the access policy.
B. Although ABAC works with AWS Secrets Manager and S3, at time of writing, ABAC does not work with all AWS services.
B. Although ABAC controls bucket objects and folders, it cannot control individual buckets.
C. Decisions about a user’s access under ABAC is defined using XACML (Extensible Access Control Markup Language) which uses Boolean logic following an IF, THEN format. XACML is a complex, dated language which requires expert skills. This can make ABAC development a error-prone and time-consuming process.
XACML is outdated today in that it was first approved in 2003, with version 3.0 in use since 2013. XACML was created to be a standard language for businesses’ – XACML was designed to control networking Authorization across-the-board rather than for policies applicable to each specific points of access (email, Internet, etc.).
D. XACML was defined by OASIS (owned by technical companies) for coding by development teams rather than business owners or compliance teams.
The concent of PBAC (from PlainID.com) is to use a more “human friendly” or “business friendly” language to code policies which provide more visibility into the relationship between identities and resources.
“PBAC is an emerging model that seeks to help enterprises address the need to implement concrete access controls based on abstract policy and governance requirements.”
This is because PBAC is an automatic process (requiring much less manual toil than RBAC).
Azure ABAC vs RBAC
In Azure, a Role is a collection of Actions that the assigned identity will be able to perform. A Role answers the question “What can be done?”
PROTIP: Azure allows only up to 2,000 Role assignments per account.
https://www.youtube.com/watch?v=xUUxxtgcRzw” title=”Jun 18, 2021”> Manage access to Azure resources at scale using Attribute Based Access Control (ABAC)</a> by Azure Power Lunch
And Okta Identity Source too
Okta is very common within enterprises. The Applications Okta manages span many vendors (AWS, Azure, Office365, Google Workspace (Gmail), Box, Atlassian, Zoom, Slack, Workday, etc.). VIDEO: Provisioning settings of a Base URL, API Token, Import Groups.
The Okta GUI accessed by users lists a “chicklet” for each application??? managed by Okta.
Click on the AWS app chicklet to open AWS SSO.
In AWS SSO, select a Permission Set, which opens an AWS Management Console GUI.
Assignment of People and Groups. Within AWS SSO, users are manually Enabled/Disabled.
VIDEO: Okta IdP SAML Response file (in XML format), Okta Admin GUI.
VIDEO: Okta sends SAML Authentication assertions using SCIM sync protocol to make ABAC asserts to AWS SSO.
VIDEO: DEMO: The “Okta Workflows Connector for AWS SSO” (with Pre-built Okta Workflows like IFTTT) uses a drag-and-drop GUI to design actions within Okta which call AWS APIs to automatically manipulate Entitlements (Accounts and Permission Set):
Attribute (Tag) Design
The “Attribute” in ABAC refers to adding Tags which the system references when determining authorization based on condition statements in a Permissions Policy file in JSON format.
A particular user obtains permissions (such as in Production) when an administrator adds a Tag to the user’s account.
??? The AWS Role (such as AWSDeveloper, Tester, Operator, etc.).
In the GUI
In CloudFormation …
In Terraform …
VIDEO: Administrators use AWS Single Sign-on GUI to assign to each User/Group name its Permission Sets (Okta Group).
Sample groups segregate by traditional human organization boundaries such as:
PROTIP: In advanced organizations, an individual may wear several hats (Developer, SRE, Tester, etc.).
[8:04] “Updated by” SCIM (System Cross-domain Identity Management) Provisioning.
Onboarding Users in AWS
https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html AWS BLOG: What is ABAC for AWS?
https://www.youtube.com/watch?v=Iq_hDc385t4 https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html AWS BLOG: IAM JSON policy elements: Condition
https://www.youtube.com/watch?v=m2ksemtAB10 Attribute-Based Access Control in Hyperledger Fabric a Blockchain Platform Access control decisions can be made by chaincode …
1-Minute IAM Lesson by Cloud Bart
https://www.strongdm.com/blog/rbac-vs-abac by Maile McCarthy January 5, 2022