Policies & Permissions Flashcards
What are Policies?
Polices basically = permissions & can be Identity-Based Policies and
Resource-Based Policies
- In Other Words*
- Policies** (Essentially Permissions*) - (Policies => Policy Documents => JSON files => permissions
- Policies** (permissions*) can be attached to users or groups
- *Policy** documents sit on top of Users/Groups/Roles
Policy language
Policy language
- provide authorisation (not authentication)
- two parts:
- Specification ‘defining’ access policies
- Enforcement ‘evaluating’ access policies
Policy Specification basics:
Four part = PARC
- json document
- Contains a statement ‘permission’ that specifies what Action a principal can perform & which Resources can be accessed
Policies Key Points - Contd.
- Policies/Policy Language (PARC = Principals, Action , Resource & Condition) ;
- Policy actions are classified as List, Read, Write, Permissions management, or Tagging.
- Policy Documents >> Effect = Single Word = ALLOW/DENY ; Service Which AWS cloud service ; Resource specifies specific ARN , ARN format varies slightly dependant on service (e.g: arn:aws:service:region:account-id:resource type
- AWS offer a policy generator tool self written policies can be tested by policy simulator
- API calls - API calls require access keys (API keys) ; API keys are also managed at the account level ;
- AWS only applies policies once authenticated an explicit deny always override an explicit allow never pass API keys to EC2 instances never store API keys on the Instance best practice is to delete root access key of the first root account
Policy Enforcement basics:
- Policy Enforcement - AWS decision Starts by deny collect or policies compare them and DENY will always win
Types of IAM Policies & Other Policies that follow the PARC policy language
- AWS Organisations (OU) - Service control policies or SCP
- AWS IAM - Identity-based policies can be Managed or Inline (stay with user)
- AWS STS - scope down policies ; during assume role call assume least privileged role (Typically AWS find that customers generally WRITE general ROLES and then use STS to SCOPE them down more)
- AWS Specific Services - Resource-based policies are inline only, not managed. Usually only on Queries Vaults E.g Amazon S3 bucket policy ; cross account access controlled access from the Resource or via roles
Resource-based policies (Inline Only)
- Resource-based policies differ from resource-level permissions. You can attach resource-based policies directly to a resource, as described in this topic. Resource-level permissions refer to the ability to use ARNs to specify individual resources in a policy. Resource-based policies are supported only by some AWS services. For a list of which services support resource-based policies and resource-level permissions
- The following services support resource-based policies for the specified resources: Amazon Simple Storage Service (S3) buckets, Amazon Glacier vaults, Amazon Simple Notification Service (SNS) topics, and Amazon Simple Queue Service (SQS) queues
Identity-based policies - Managed Policies or Inline Policies ?
Choosing Between Managed Policies and Inline Policies
- The different types of policies are for different use cases. In most cases, we recommend that you use managed policies instead of inline policies.
Managed policies features?
Provide the following features:
- Reusability
- Central change management
- Versioning and rolling back
- Delegating permissions management
- Automatic updates for AWS managed policies
Managed policies: Reusability
- A single managed policy can be attached to multiple principal entities (users, groups, and roles). In effect, you can create a library of policies that define permissions that are useful for your AWS account, and then attach these policies to principal entities as needed.
Managed policies: Central change management
When you change a managed policy, the change is applied to all principal entities that the policy is attached to.
E.g: if you want to add permission for a new AWS API, you can update the managed policy to add the permission.
(If you’re using an AWS managed policy, AWS updates to the policy.)
When the policy is updated, the changes are applied to all principal entities that the policy is attached to. In contrast, to change an inline policy you must individually edit each principal entity that contains the policy. For example, if a group and a role both contain the same inline policy, you must individually edit both principal entities in order to change that policy
Managed policies: Versioning and rolling back
When you change a customer managed policy, the changed policy doesn’t overwrite the existing policy. Instead, IAM creates a new version of the managed policy. IAM stores up to five versions of your customer managed policies. You can use policy versions to revert a policy to an earlier version if you need to.
A policy version is different from a Version policy element. The Version policy element is used within a policy and defines the version of the policy language. To learn more about policy versions, see Versioning IAM Policies.
Managed policies: Delegating permissions management
- You can allow users in your AWS account to attach and detach policies while maintaining control over the permissions defined in those policies. In effect, you can designate some users as full administrators—that is, administrators that can create, update, and delete policies. You can then designate other users as limited administrators. That is, administrators that can attach policies to other principal entities, but only the policies that you have allowed them to attach.
Managed policies: Automatic updates for AWS managed policies
AWS maintains AWS managed policies and updates them when necessary (for example, to add permissions for new AWS services), without you having to make changes. The updates are automatically applied to the principal entities that you have attached the AWS managed policy to.
Inline Policies
- An inline policy is a policy that’s embedded in a principal entity (a user, group, or role)—that is, the policy is an inherent part of the principal entity. You can create a policy and embed it in a principal entity, either when you create the principal entity or later.
Using Inline Policies
- Inline policies are useful if you want to maintain a strict one-to-one relationship between a policy and the principal entity that it’s applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to a principal entity other than the one they’re intended for.
- When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong principal entity. In addition, when you use the AWS Management Console to delete that principal entity, the policies embedded in the principal entity are deleted as well. That’s because they are part of the principal entity.
AWS Policy Permissions Enforcements Overview
For the Same Account
Provided there is an ALLOW from the Top OU
Then the ‘permissions’ are enforced by :
UNION OF >> Service control SCP + Managed & Inline Polies
+
INTERSECTION OF >>AWS STS (scope down policies)
+
UNION OF >> >> AWS Specific Services (Resource Based Policies)
