Identity access management (IAM) becomes increasingly complex as organizations grow from startups to large enterprises. Initially, with a small team, managing access and identity is simple, but as the company expands, so does the need for enhanced IAM systems. New hires, department restructuring, and the introduction of cloud platforms like AWS further complicate IAM. Learn how AWS IAM Identity Center and Service Control Policies via AWS Organizations can help streamline user and group management, while maintaining robust security.
Before going deep in hooking up all kinds of different services together, let’s begin with a bit of context. To put all the different services and acronyms in their right place.
If you’re familiar with the relevant AWS services, you can skip to part 2 of the blog.
IAM Policies 101
I often summarise access control in AWS with this statement.
Denied unless Allowed unless Denied.
What this means is that, by default, an entity within AWS has no rights to do anything unless these rights have been given AND, and this is the important part, they have not been explicitly denied.
So, written out fully, it’s Implicitly Denied until Explicitly Allowed until Explicitly Denied.
Within AWS what is allowed or denied to an entity is defined within Identity Access Management (IAM) policies. These policies are JSON formatted documents that define what a “principal” is allowed to do or, more importantly, not allowed to do within a certain context.
This principal is the initiator of the action and can be an IAM user or an application because within AWS, nothing and no-one is allowed to do anything without an IAM policy allowing it to do so.
Policies do not live in a vacuum. Policies are attached to things. These things differ depending on the policy.
If the policy is identity-based, they are assigned to roles or groups which in turn are assumed by (roles) or assigned to (groups) users or other AWS resources.
If its resource based, the policy is attached directly to an AWS resource that will then be used to determine what rights the interacting principal has on this resource.
The components of these policies are as follows:
• Version: The policy language version so that AWS can correctly parse the data defined in the policy. Two exist, the older 2008-10-17 and the current 2012-10-17.
• Statement: Contains one or multiple policy statements.
Within the statement, policies are defined with the following.
Principal
Defines the principal (initiator of the action) that this policy statement applies to.
A principal, when defined must map against an IAM or STS user, group or role or an AWS Service. These can be as broad as an entire AWS account or as narrow as a single IAM user.
Examples:
AWS Account:
"Principal": {"AWS": "arn:aws:iam::045676890123:root"}
AWS Service:
"Principal": {"Service": "delivery.logs.amazonaws.com"}
STS Assumed Role:
"Principal": {"AWS": "arn:aws:sts::045676890123:assumed-role/{rolename}"}
AWS Role:
"Principal": {"AWS": "arn:aws:iam::045676890123:role/{rolename}"}
If the policy is used in an identity-manner, it is not required to be defined because it is inferred by the principal the policy is attached too.
If the attached is used as a resource-based object however, it is required to define what principals are allowed to interact with the resource.
Effect
Does the policy either “Allow” or “Deny” the action defined in the policy.
Action
Define an action within AWS.
Actions are defined as “{service}:{action}” where part or the entirety can be replaced with a wildcard *. Examples are:
"Action": "s3:PutObject"
This action allows for the writing of an object into S3.
"Action": "kms:*"
This action allows every action within the Key Management Service (KMS)
"Action": "*"
This action allows everything.
If not secured with either a Resource or a Condition statement, it will allow full access to every part of an AWS account or resource.
Actions can be defined as “Action” or “NotAction” creating a white or blacklist respectively. Combined with Effect:Deny, double-negative style allows can be created. We will zoom in on this later.
Resource
Define the AWS resource that the Action is limited too. This resource must be defined with an AWS ARN and one or more wildcards (*) can be used to broaden the scope of the resource(s) under the policy.
Examples are:
"Resource": "arn:aws:s3:::accesslogs/*"
Which defines all objects within an S3 bucket called “accesslogs”
"Resource": "arn:aws:kms:eu-west-1:045676890123:key/87132241-9a03-4c89-a723-af0b43aea2bc7"
Which defines a specific KMS key within account 045676890123 in AWS Region eu-west-1
"Resource": "*"
Which defines all resources
Condition
Conditions is an optional statement that can contain one or more sub-statements where further allowances or limitations can be made on top of Principal/Action and Resource.
Within conditions, logic checks can be performed. For example, comparing values from the calling principal to the targeted resource. Another often used condition is to check (and then block) for unencrypted traffic.
Full Policies
Bringing all these together will create policies as these two examples:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
This identity-based policy allows administrator rights to the entire AWS Account.
{
"Version": "2012-10-17",
"Statement": [
{
"Principal": {
"AWS": "arn:aws:iam::045676890123:root"
},
"Effect": "Allow",
"Action": "S3:PutObject",
"Resource": "arn:aws:s3:::accesslogs/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
}
}
}
]
}
This resource-based policy allows all principals from the account 045676890123 to write into the bucket “access logs” as long as the connection is encrypted.
Bringing it home
When a request is made within AWS all the policies attached to the identity requesting and the resources requested from are taken and combined into a single policy. Then, if at least one “Allow” to the resource and no “Deny” is found, access is given.
If, however, a “Deny” is found, the request will be denied, even though an “Allow” for that same request exists.
AWS Organizations (Service name, further abbreviated to AWS Org) is designed to be used by organisations (EN-UK spelling) to centrally manage AWS accounts under their ownership more effectively.
It allows for grouping AWS accounts in a hierarchical method using one or multiple levels of organizational units (OU) based on the requirements of the organisation.
These OUs will house one or more AWS accounts and can have several types of policies attached to either the OU or accounts directly to allow management on a high or granular level. The available policy types are.
- Backup policy – Ensure consistency in how AWS Backup plans are implemented
- Tag policies – Standardise tags on all supported resources
- Service control Policies (SCP) – Control IAM permissions within the AWS account
- AI services opt-out policies – Control what AI Services can store and what content within an account it can use to do its job
When a policy is applied to an OU, the policy will affect all child OUs and AWS accounts within those OUs.
Service control policies (SCP)
Service control policies (SCP) introduce an extra level of securing AWS accounts by granting or denying access to resources.
We’ve spoken about IAM policies. How they are constructed and how identity and resource-based policies grant or deny access for a request.
What is important to know at this stage is that that an extra step is introduced when AWS Org is enabled.
Where before, only Resource and Identity based policies (and permission boundaries but I am leaving these out right now for the sake of simplicity) were at work determining if a request for access was to be allowed or denied. With the introduction of SCPs, they will also weigh in if a request will be allowed or denied.
Tagging policies
The last component I want to highlight within AWS Organizations is tagging policies. These policies can enforce the way resources can be tagged.
*They however do not enforce a specific tag being used. *
{
"tags": {
"deparment": {
"tag_key": {
"@@assign": "Department"
},
"tag_value": {
"@@assign": [
"finance",
"sales",
"security"
]
},
"enforced_for": {
"@@assign": [
"ec2:instance",
"kms:*"
]
}
}
}
}
As an example, this policy defines that if the tag “Department” is used, it must have one of the three values defined in “tag_value”. Furthermore, this enforcement is then only done on ec2:instance and all kms resources.
It’s important to fully understand the goal of tagging policies. They are designed to be used for compliance reasons. Using the Management console or the AWS CLI, you can generate a report of non-compliant resources to allow for correction later.
Also, not all resources can be tagged. “ec2:*”for instance is not supported and specific resources must be defined. A complete list can be found here
Enabling AWS Org will also enable other services and enable centralised management functionally of existing services. A sample of services which are important to AWS Org or relevant to this document are the following:
Centralised billing - Free
Enabling AWS Org instantly turns the account that created it into the “master billing account” (MBA), also known as the Root account. What this means is any account in the AWS Org, including itself, reports its AWS service usage to the MBA from where a single billing dashboard will be available, and a single bill will be generated and paid out to AWS. The consolidated billing dashboard is free to use and a great way to analyse costs across the accounts in the AWS Org by service, account or any tagging enabled for billing purposes.
AWS IAM Identity Center (successor to AWS SSO) – Free
This service used has been recently renamed from AWS Single Sign-On (SSO) which is why the name right now is a mouth full as both are being used in this transition phase.
Identity Center enables the organization to centrally manage and control the AWS Management Console and API access for Users and Groups across all AWS Accounts within the Organization. This is done by using either the built-in Users and Groups functionality of IAM-IC or by connecting to a third-party Identity provider (IdP) like Okta or AzureAD.
We will go in further detail in the next chapter.
Enterprise support – Paid
Standard AWS accounts have three tiers of support.
- Basic, which allows only for account, billing and business support cases.
- Developer, which opens up the capability of logging technical support cases.
- Business, which adds P1 and P2 urgency to support cases and give quicker support.
With an Organisation, a fourth tier opens; Enterprise support. (Which itself split up in two tiers. Enterprise On-Ramp and Enterprise.)
The first three tiers of support were set on an account level. Enterprise support is set at the organizational level and allows for every single account to have the highest grade of support available.
AWS IAM Identity Center
“AWS IAM Identity Center (successor to AWS SSO)” is the single sign-on solution for AWS accounts joined together within an AWS Org. Identity Center gives a centralised location to manage users and group, their access to AWS accounts within the organization and what rights they have within those accounts using Permission sets. By default, the root account of the AWS Org is the administrator of Identity Center but this can be delegated to, for instance, a dedicated IAM or Security account. This will prevent to many users accessing the, arguably, most important account within the AWS Org.
A permission set is a structure that contains one or more of the following IAM policies:
- AWS Managed Policies
- Customer managed policies
- Inline Policy, so defined directly inside the permission set
- Optionally, a permissions boundary.
When a Permission set is provisioned in a member account, an IAM role is created with policies that correspond to the specific rights defined within the permission set. E.g., an attached policy or an inline policy. These IAM roles (and policies) are protected entities that cannot be modified from the member account.
When a user logs in via Identity Center, they can then assume the IAM role in the member account to work within this account within the boundaries defined in the IAM role.
The power of AWS IAM Identity Center lies in its capability of integrating with Security Assertion Markup Language (SAML) 2.0 compliant Identity providers (IdP). Most organisations already use an identity provider to manage their users with providers like Okta, Active Directory Federation Services (ADFS) or Ping among others.
Going one step further, by using System for Cross-Domain Identity Management (SCIM), users and groups can be synchronised automatically from the SAML IdP into IAM-IC.
The result of this allows organisations to setup a single sign-on environment where users can access AWS with the same credentials they use for their workstation, email, or other work environments. Often without having to even fill in their credentials again.
Attribute based access control
Identity Center also introduces a feature that is not enabled by default and slightly hidden away but allows organisations to manage user access in an entirely new way by basing access on enterprise specific parameters, which is called Attribute-based access control (ABAC).
In a simple Azure AD SAML & SCIM setup, only these user attributes are synchronised:
https://docs.aws.amazon.com/singlesignon/latest/userguide/attributemappingsconcept.html
These attributes are the ones minimally required to perform successful logins into AWS.
What ABAC allows for is to sync more attributes from AAD into Identity Center.
Examples of these are department and cost centre. Or office location and function title.
By passing these attributes into AWS and linking them in ABAC, direct references to these can be made by Identity Provider.
These attributes, as the name of the service implies, can then be used to help dictate access for users within AWS.
Now, let’s bring all these components together and use them in tandem to provide easy, secure, and flexible access into AWS.
Top comments (0)