A deep dive into IAM Policies
How do you manage access in AWS?
You manage access in AWS by attaching policies to IAM identities and resources that reside within an account.
IAM policies allow you to be as granular as you’d like. You can allow access to all of the resources in your account or only one.
A policy, as defined in the context of AWS, is an object that, when associated with an identity or resource that defines its permissions.
AWS Resources
This element specifies the object or objects that the statement covers. It is specified using the Amazon Resource Name, or ARN. Each service has its own set of resources
Identity-based policies
Attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.
Inline Policies
These are added directly to a user or group and maintain a strict one-to-one relationship with the policy and identity.
They are generally created when you create an identity and deleted when the identity is deleted.
Their usefulness comes from the one-to-one relationship. They are part of the principal identity.
An inline policy is attached to the single entity.
The disadvantage of inline policy
Needing to create a new policy for every identity and having that policy go away whenever the identity is deleted becomes very difficult to manage when you start looking at dozens, hundreds, or even more of the identities.
In reality, there is a lot of shared access that you can utilize, and the ability to use condition elements in your policies gives you other ways to provide similar styles of access when you don’t necessarily need the one-to-one relationship.
Managed policies
Managed policies are standalone identity-based policies that you can attach to multiple users, groups, and roles within the account.
Managed policies are of two types: AWS managed and customer-managed policies
AWS managed Policy:
AWS managed policies are created and managed by AWS, providing more generalized access.
For Example, Amazon S3 read-only access or S3 full access.
They wouldn’t be bucket-specific, just high-level to provide permissions that are commonly seen.
Essentially, they’re designed to align closely to commonly used job functions in the IT industry. The intent is to make granting permissions for these common job functions easy.
AWS-managed policies cannot be changed. AWS will manage and update the policies as necessary.
Customer managed Policy:
If you want a policy that you can fully control and maintain, you can use a customer-managed policy
Customer-managed policies are created and managed by you, the customer.
They live in your account and enable you to have more precise control over your policies than the AWS-managed policies.
These can be attached to multiple entities within your account and can make it much easier to scale when you’re working with larger organizations
For example, you have 10 groups in your account that all need the same type of Amazon S3 access to a specific bucket location. And you need the users of all of those groups to be able to write to that specific location.
You can create one customer-managed policy and attach it to all 10 groups in order to give everyone the permission they need. And if you change that policy, it’s changed for all attached entities, providing you built-in, and centralized, change management for those managed policies.
You have full control and you are able to manage permissions at any level you feel is necessary.
Another helpful feature of customer-managed policies is versioning and rollback.
When you change a customer-managed policy, the new policy doesn’t overwrite the existing one. Instead, a new version of the policy is created and stored within AWS IAM.
Resource-based policies
Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and define under what conditions this applies. Resource-based policies are inline policies. There are no managed resource-based policies.
These are used to grant permissions to the principal that is specified in the policy whether they are within the same account, a different account, or outside of AWS altogether.
Difference between Identity-based Policy and Resource-based Policy
One of the primary differences you’ll notice is that the resource-based policies make use of the principal element, whereas the identity-based policies do not.
That is because the principal the policy applies to is the identity to which the policy is attached.
With resource-based policies, the policy is attached to a resource so the principal to which the permissions apply needs to be specifically stated
Roles
Roles may be the most important type of identity that you’ll encounter in AWS. Once assumed, you’re granted the permissions associated with that role.
The permissions granted are not added to the permissions you might already have.
When a role is assumed, the user temporarily gives up their permissions in exchange for those granted by the role.
When the role is exited, the identity’s original or default permissions are automatically restored.
For example: let’s say your permissions allow working with Amazon EC2 instances, but the role’s permission policy only grants Amazon S3 access.
In this scenario, while using the role, you cannot work with Amazon EC2 instances, but you would only have the S3 access granted by the role.
Trust Policy
A role’s key function is to delegate access.
In order to delegate that access through a role, you need to grant permissions through what is called a trust policy.
A trust policy is technically a resource policy, as the policy is attached to a resource and not an identity
A trust policy is necessary to specify the entities or “principals” allowed to use it.
Evaluation Logic for policies
Resource and identity-based policies are both permission policies and are evaluated together.
If a policy does not have an explicit deny, or an explicit allow, it is implicitly denied by default
An explicit deny will always override an explicit allow
AWS evaluates all the permissions granted by the identity-based and resource-based policies. The resulting permissions are the total permissions of the two types. If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action, except if an explicit deny isn’t either of these policies and then that will override the allow.
AWS Policy Generator
The AWS policy generator is a free resource that exists outside of the AWS Management Console.
Link: https://awspolicygen.s3.amazonaws.com/policygen.html
You can also create policies by copying one of the example policies from the below site and customize it to your needs
Link:https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html
