In the last blog, we discussed some approaches and best practices. You can even consider some of these. Well, that was just the beginning and there are even more. Let’s dive into other approaches while configuring & managing AWS IAM.
IAM Approaches
- policy type selection
AWS IAM provides three types of policy attachments. A user can use any one of them and take benefit of any policy type. The formation type & language is the same for every policy type but the difference is the scope & concept. We’ll talk about these policy types and their use cases.
Policies:
- AWS custom managed policy
- AWS managed policy
- AWS Inline policy
AWS custom managed policy:
AWS custom managed policy is a widely used policy for AWS IAM entity. The main reason for using AWS custom managed policy is flexibility & scope. We can easily customize according to use-cases. The custom managed policy also supports multiple conditions-based approaches through which we can easily utilize the benefits of the custom managed policy.
Here is a twist in AWS custom managed policy, there is a create the limitation of custom managed policy. According to the official documentation, there is a default limit of 1500 for custom managed policy per account and users cannot create extra policy more than default limit counts. If there is a requirement of more than the default limit, the user can request AWS to increase from 1500 to 5000 which is the last and hard limit of the custom managed policy.
Managed policy:
AWS managed policy is a standalone identity-based policy that is managed, created & maintained by AWS. Any entity cannot change these types of identity-based policies. Any entity can use these AWS-managed policies for any AWS options like role, users, groups, etc. You can get more options from amazon official documentation for multiple AWS managed policy options like billing access, AWS EC2 read-only, etc.
AWS managed these policies itself which means they have full control of managed policy. AWS can modify, update, delete, remove functionality of AWS managed policy and it will affect those entities that are utilizing those policies. AWS updates these managed policies when there is a new feature or update on specific environments. Sometimes, it doesn’t matter but at times it can change the whole perspective of that resource utilization.
AWS managed policy cannot provide full functionality as the custom managed policy provides but we can use AWS managed policy in some ways that it will not occupy space or use any custom managed policy counts. There are plenty of options where we can use AWS managed policy and one of the examples is if someone wants read access to EC2 or any other AWS resource without any condition. So, without creating AWS custom managed policy there is managed policy provided by AWS for the same purpose and we can use AWS managed policy for the same.
When we talk about AWS custom managed policy which is a far better option than AWS managed policy, there is one issue with the custom managed policy, that is a quota. We cannot create an unlimited AWS custom-managed policy and this is a concern where there is a large number of environments, teams, infrastructure, AWS resource utilization present.
Inline policy:
As we have already discussed in our last blog about inline policy. The inline policy is one of a kind and alternatives for AWS managed & custom managed policy. When we talk about AWS managed & custom managed policy, we’re bound to some limitations and these are flexibility & quota.
The inline policy is a better approach when we want flexibility like AWS custom managed policy & there is no soft or hard limit for creating IAM policy. As per official documentation, there is no limit to IAM inline policy and inline policy can attach to any IAM options like user, role & group.
But there is a limitation of inline policy. It is the scope, which means when we create an inline policy for one entity, it will remain the same for that specific entity and cannot be transferred or used for another IAM entity.
- Policy Validation
When we create policies using AWS console or policy generator, we generally get a base template and try to modify it, which usually leads to some issues like syntax error and security issues that often get neglected.
To overcome these issues, AWS IAM provided policy validation tool IAM Access Analyzer Update, which generally validates and provides errors. IAM Access Analyzer Update tool is not only used to validate the errors but also to provide multiple functionalities like :
– Security
– Errors [Default]
– Warning
– Suggestions
The above validation is used to make proper generate/creation of IAM policy. Each part is used to validate different things. Let’s talk about each part and know their uses and how it works:
Security: When we talk about security options in IAM Access Analyzer Update, it generally focuses on over permissive access, which is generally fetched by AWS itself, and considers that over permissive access as a security issue and throws warning while configuring or creating IAM policy.
Some of the security warnings are,
– Allow with NotPrincipal
– Pass role with NotResource
– Pass role with star in resource
There are even more, it is a very good practice to follow and consider these security checks for security approaches.
Errors: These options generally consider errors that are related to syntax like incorrect name, syntax errors, invalid versions, missing fields, elements field related issue etc. All these checks are managed and watched by the AWS IAM Access Analyzer Validation tool.
Warning: There are some IAM policy checks which cannot get picked by the `ERROR` option. So, warning generally provides checks which generally do not fail policy creation but are considered to be failed when we use it.
Few of the checks that warning option include:
– Type mismatch for multiple options
– Invalid values like date, user etc.
– Unique SID recommendations
Suggestions: Suggestions refers to empty, missing & redundant values.
These are the checks which are consider by suggestions options:
– Empty array actions
– Redundant actions
– Wildcards in service name
If we consider these options while configuring AWS IAM policies, it clears many doubts & issues while creating IAM policies. For more and detailed information, check the official documentation.
- AWS STS
When we talk about proving temporary credentials for multiple use cases, that’s where “AWS STS” comes into the picture. AWS STS is a web service that enables a user to request temporary, limited privileged credentials for IAM users or federated users.
There are some basic use cases and yes temporary credentials can be very effective when we want to connect two different AWS accounts. Let’s take a case, if we want to access account A resources from account B [cross-account use-case]. There is only one option which is creating a user on account A and attaching account A secret credentials to the resource of account B which is generally not a good practice. There can be multiple reasons:
– Creating user for every use-case, which can cause limitation issue
– Management of these cross-accounts can be hectic
-We are providing permanent credentials or the credentials that can be used by anyone at any time. This can cause security issues
AWS security token service or AWS STS is used to provide temporary credentials using its endpoint: https://sts.amazonaws.com. These keys are generated dynamically and provided to the user when requested for using in multiple ways. For cross-account access, the AssumeRole API action is used to obtain temporary credentials. There is even more API action present for STS:
– AssumeRole
– AssumeRoleWithSAML
– AssumeRoleWithWebIdentity
– DecodeAuthorizationMessage
– GetAccessKeyInfo
– GetCallerIdentity
– GetFederatedToken
– GetSessionToken
The above diagram is an example of AassumeRole API action as resource B is trying to access resource A. Below is the command, through which we can get temporary credentials for a limited duration of time. STS provides these things for temporary access:
– Access Key
– Secret Access Key
– Session Token
– Expiration
Command –
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/<ROLE-NAME> --role-session-name “ROLE”-NAME --profile <PROFILE-NAME>Output –
{
"Credentials": {
"AccessKeyId": "<ACCESS-KEY>",
"SecretAccessKey": "<SECRET-KEY>",
"SessionToken": "<SERVICE-TOKEN>",
"Expiration": "2021-05-26T19:48:30Z"
},
"AssumedRoleUser": {
"AssumedRoleId": “<ID>:r<ROLE-NAME>,
"Arn": "arn:aws:sts::123456789012:assumed-role/<ROLE-NAME>/<ROLE-NAME>”
}
}
AWS STS is good for scenarios where temporary security credentials are required and we assumed only one type of scenario which is cross-account access. There are lots of scenarios where these temporary credentials are used like:
– Identity federation
– Delegation
– IAM roles
Conclusion
AWS provided multiple types of identity-access policy like Managed policy, inline policy & Custom policy for different use cases. AWS IAM access analyzer validation tool consists of four options: suggestions, errors, warning & security. Temporary credentials can be considered for identity federation, delegation, cross-account access, IAM roles. AWS Security Token Service (AWS STS) is a web service that enables you to request temporary, limited-privilege credentials. AWS roles use AWS STS for temporary credentials.
This blog considers all the approaches or options provided by AWS itself and you can consider them in your AWS IAM management. Even these options are not mandatory but AWS suggests these approaches as one of the best practices and suggests user to use them for many scenarios. The next blog will focus on the best practices – The security edition, which mainly focuses on approaches based on implementing security options.
If you want more series related to the best approaches, please let us know in the comment section.
Blog Pundit: Naveen Verma
Opstree is an End to End DevOps solution provider
2 thoughts on “AWS IAM: Best practices [ part 2 ]”