IAM Bullet points

Notes on IAM (AWS):

I have decided to summarize the essential points of what I have learned about IAM. This is a bullet point summary of the essential points.

  1. The account and the user inside the account are two different entities
  2. The user in the account is an IAM identity – also known as a PRINCIPAL
  3. Identities can be federated – users w/o AWS accounts can be given temporary permissions
  4. IAM is shorthand for Identity and Access Management
  5. A root user is automatically created along with the creation of the account; but the root user is an identity inside the AWS account, not the account itself
  6. After creation, the root user should be locked down using MFA
  7. An IAM user should be created and granted administrative privileges by attaching a policy to the user granting those policies
  8. There is a hard limit of 5,000 IAM users per account; each user can be a member of 10 groups
  9. Policies identify actions that relate to AWS resources and the effect permitted by those actions
  10. There is a pool of created policies available for use in AWS; alternately, policies can be created to suit custom needs
  11. Policies are created using either the Create policy page or using JSON
  12. Policies can be attached to either principals (aka ‘identity-based’ policies) or resources (aka ‘resource-based’ policies)
  13. An attempt to access AWS resources is a two-step process: first the user is AUTHENTICATED inside the account, and then access to resources in that account are AUTHORIZED
  14. All actions in AWS are implicitly denied; granting permissions requires that actions be allowed through the administering of policies
  15. There are two types of ‘deny’ – implicit and explicit; all actions are implicitly denied, and an explicit deny can be used to refine allows
  16. A single entity can have up to 10 managed policies attached (policies limited to 6,144 characters)
  17. Policy administration is divided into two types: inline (individually applied to each user) and through the use of groups
  18. Groups are containers for users; they cannot be logged into and have no credentials of their own, and they cannot be nested
  19. Groups allow for a set of policies to be applied to a whole class of users, which greatly simplifies management of those policies
  20. Roles are used to grant temporary permissions to users or services that exist outside a particular AWS account
  21. Access to programming/CLI-based resources requires the creation of access keys

Published by pauldparadis

Working towards cloud networking security as a profession.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: