IAM (Identity and Access Management)
- Gives you centralised control of an AWS account
- Is global - there is no concept of regional IAM at this time; all users, groups, policies, etc are available in all regions.
- Supports Identity Federation which can be used for Single Sign-on i.e. via SAML
- Can be used to give temporary access
IAM consists of Users, Groups Roles, and Policy Documents
Users
Are the individual accounts.
By default, new users don’t have access to any AWS services.
Always set up MFA (Multifactor Authentication) on your root account.
IAM can be used to create and customise password rotation policies.
There are two ways to access AWS:
- Username + Password
- Access Key ID + Secret Access Key
Username and Password
- Cannot be used to interact with the API
- Can be used to sign in via a custom sign-in link which you can create via the IAM console i.e.
Access Key ID and Secret Access Key
- Assigned on user creation
- Can be used to interact via the AWS command line, SDKs, or APIs.
- Not the same as Username and Password.
- Can only be viewed once. If you lose them, they need to be regenerated. Save them in a secure location.
Groups
Are a collection of IAM users, simplifying the assigning of permissions. i.e. you can have groups for different departments such as Sales, Developers, HR, etc, which may all require different levels of AWS access.
- A user can belong to multiple groups
- Groups cannot belong to other groups
Roles
You can create roles, then assign them to AWS resources.
i.e. you might have an EC2 instance, and give it a role saying it can access S3. That way the EC2 instance can directly access S3 without having to manage usernames, passwords, etc.
Limited to 500 IAM roles under your AWS account. The acloud.guru course states up to 250.
Role types:
- AWS Service
- Another AWS Account (allows entities in other accounts to perform actions in the current account)
- Web Identity (Amazon, Cognito, Facebook, Google)
- SAML / OpenID Connect
API Actions for assuming roles:
- AssumeRole
- You cannot call AssumeRole by using AWS root account credentials; access is denied. You must use credentials for an IAM user or an IAM role to call AssumeRole.
- AssumeRoleWithSAML - for when users have been authenticated via a SAML authentication response, i.e. an on-premises VPC
- AssumeRoleWithWebIdentity (when users have been authenticated in a mobile app or web app with a web identity provider suh as Facebook, Google, or OpenID connect)
Including an IAM access policy with AssumeRole
When assuming a role, you can futher restrict access via passing an IAM access policy on each request.
If you pass a policy to this operation, the temporary security credentials that are returned by the operation have:
- the permissions that are allowed by both the access policy of the role that is being assumed
- and the policy that you pass.
… this gives you a way to further restrict the permissions for the resulting temporary security credentials.
You cannot use the passed policy to grant permissions that are in excess of those allowed by the access policy of the role that is being assumed.
Policy Documents
An IAM policy is a document which formally defines permissions, and can be attached to users, groups, and roles.
The “ PowerUserAccess” policy provides full access to AWS services and resources, but does not allow management of users and groups.
For example, here’s one of the default AWS policy documents for assigning full access to S3:
STS (Secure Token Service)
STS is used for requesting temporary, limited-privilege credentials for AWS IAM users or for federated users which you authenticate.
The temporary security credentials are valid for the duration that you specified when calling AssumeRole, which can be from 900 seconds (15 minutes) to a maximum of 3600 seconds (1 hour). The default is 1 hour. More info
Supports the following sources:
- Federation (typically Active Directory)
- Uses SAML
- Allows you to use credentials from another provider (i.e. Active Directory) - does not need to be IAM credentials
- Does not need to be a user in IAM, or need any IAM credentials
- Federation with mobile apps
- Using Facebook/Amazon/Google or other OpenID provider to log in
- Cross-account access - allowing users from AWS account to access resources in another
To use STS Federation, you must implement the following steps in the following order:
- Develop an Identity Broker to communiate with LDAP (Lightweight Directory Access Protocol, one of the protocols that you can use to talk to Active Directory) and STS
- Identity Broker always authenticates with LDAP first, THEN with AWS STS
- Application then gets temporary access to AWS resources
Web Identity Federation
Useful for mobile apps which need to access AWS resources, and allows the app to aeceve an auth token, and then use that token for temporary credentials.
It’s strongly recommended to not embed or distribute long-term AWS credentials with apps that are user downloads to a device.
Web Identity Federation supports the following providers:
- Amazon
- Any other OpenID Connect (OIDC) compatible id provider
What Is IAM?
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.
When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.
Topics
Video Introduction to IAM
AWS Training and Certification provides a 10-minute video introduction to IAM:
IAM Features
IAM gives you the following features:
- Shared access to your AWS account
- You can grant other people permission to administer and use resources in your AWS account without having to share your password or access key.
- Granular permissions
- You can grant different permissions to different people for different resources. For example, you might allow some users complete access to Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift, and other AWS services. For other users, you can allow read-only access to just some S3 buckets, or permission to administer just some EC2 instances, or to access your billing information but nothing else.
- Secure access to AWS resources for applications that run on Amazon EC2
- You can use IAM features to securely provide credentials for applications that run on EC2 instances. These credentials provide permissions for your application to access other AWS resources. Examples include S3 buckets and DynamoDB tables.
- Multi-factor authentication (MFA)
- You can add two-factor authentication to your account and to individual users for extra security. With MFA you or your users must provide not only a password or access key to work with your account, but also a code from a specially configured device.
- Identity federation
- You can allow users who already have passwords elsewhere—for example, in your corporate network or with an internet identity provider—to get temporary access to your AWS account.
- Identity information for assurance
- If you use AWS CloudTrail, you receive log records that include information about those who made requests for resources in your account. That information is based on IAM identities.
- PCI DSS Compliance
- IAM supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS). For more information about PCI DSS, including how to request a copy of the AWS PCI Compliance Package, see PCI DSS Level 1.
- Integrated with many AWS services
- For a list of AWS services that work with IAM, see AWS Services That Work with IAM.
- Eventually Consistent
- IAM, like many other AWS services, is eventually consistent. IAM achieves high availability by replicating data across multiple servers within Amazon's data centers around the world. If a request to change some data is successful, the change is committed and safely stored. However, the change must be replicated across IAM, which can take some time. Such changes include creating or updating users, groups, roles, or policies. We recommend that you do not include such IAM changes in the critical, high-availability code paths of your application. Instead, make IAM changes in a separate initialization or setup routine that you run less frequently. Also, be sure to verify that the changes have been propagated before production workflows depend on them. For more information, see Changes That I Make Are Not Always Immediately Visible.
- Free to use
- AWS Identity and Access Management (IAM) and AWS Security Token Service (AWS STS) are features of your AWS account offered at no additional charge. You are charged only when you access other AWS services using your IAM users or AWS STS temporary security credentials. For information about the pricing of other AWS products, see the Amazon Web Services pricing page.
Accessing IAM
You can work with AWS Identity and Access Management in any of the following ways.
- AWS Management Console
- The console is a browser-based interface to manage IAM and AWS resources. For more information about accessing IAM through the console, see The IAM Console and Sign-in Page. For a tutorial that guides you through using the console, see Creating Your First IAM Admin User and Group.
- AWS Command Line Tools
- You can use the AWS command line tools to issue commands at your system's command line to perform IAM and AWS tasks. Using the command line can be faster and more convenient than the console. The command line tools are also useful if you want to build scripts that perform AWS tasks.AWS provides two sets of command line tools: the AWS Command Line Interface (AWS CLI) and the AWS Tools for Windows PowerShell. For information about installing and using the AWS CLI, see the AWS Command Line Interface User Guide. For information about installing and using the Tools for Windows PowerShell, see the AWS Tools for Windows PowerShell User Guide.
- AWS SDKs
- AWS provides SDKs (software development kits) that consist of libraries and sample code for various programming languages and platforms (Java, Python, Ruby, .NET, iOS, Android, etc.). The SDKs provide a convenient way to create programmatic access to IAM and AWS. For example, the SDKs take care of tasks such as cryptographically signing requests, managing errors, and retrying requests automatically. For information about the AWS SDKs, including how to download and install them, see the Tools for Amazon Web Services page.
- IAM HTTPS API
- You can access IAM and AWS programmatically by using the IAM HTTPS API, which lets you issue HTTPS requests directly to the service. When you use the HTTPS API, you must include code to digitally sign requests using your credentials. For more information, see Calling the API by Making HTTP Query Requests and the IAM API Reference.
- What is IAM? • IAM Concepts – to help you get started • Common use cases – cover the building blocks • Demos – “Show and Tell”
- 3. AWS Identity and Access Management (IAM)
- • Enables you to control who can do what in your AWS account
- • IAM uses access control concepts that you are already familiar with User Group Permissions (IAM Policies) Role AWS Services and Resources
- 4. AWS Identity and Access Management (IAM)
- • Control – Centralized – Fine-grained - APIs, resources, and AWS Management Console
- • Security – Secure (deny) by default – Multiple users, individual security credentials and permissions
- 5. IAM Users What
- • Entity that represents the person or service that uses it to interact with AWS
- • Consists of a name and unique set of credentials
- • Console password
- • Access Key
- • MFA device (SMS, Virtual, or Hardware)
- • Each IAM user is associated with one and only one AWS account; does not require a separate payment method. When
- • Enable human or programmatic access to AWS resources and services
- • E.g. New employee, Rob, requires access to Amazon EC2 and Amazon S3 services
- • E.g. Rob has created an application that stores data in Amazon DynamoDB
- 6. IAM Users Why (Benefits)
- • Unique set of credentials • Individual permissions
- • Granular control
- • Easy to revoke access Do
- • Create IAM user for yourself
- • Create individual IAM users for others Don’t
- • Distribute your AWS root credentials
- • Use your root account user
- • Share your IAM user credentials
- 7. IAM Users and Permissions
- • No permissions by default
- • Permissions specify who has access to AWS resources, and what actions they can perform on those resources
- • Assign permissions individually to each user (or use Groups)
- • Rob (UX Designer) > access to Amazon S3
- • Samantha (Database Administrator) > access to select Amazon EC2, Amazon RDS, Amazon DynamoDB, AWS Lambda, and AWS Data Pipeline APIs
- • Use IAM Policies to assign permissions
- 8. IAM Policies
- • Contain a statement (permissions) which specify a combination of :
- • Who • What actions • Which AWS resources
- • When • Where
- • How Rob Can GET/PUT objects in S3 Bucket = “*” Until Dec 31, 2017 From IP range 123.456.789.012 If using MFA
- 9. IAM Policies
- • JSON-formatted documents Example of an Amazon S3 Read-Only Access Template { "Statement": [ { "Effect": "Allow", "Action": ["s3:Get*", "s3:List*"], "Resource": "*" } ] }
- • Attach policy to a user, group, or role (identity-based permissions)
- • Attach policy to select resources e.g. Amazon S3 buckets (resource-based permissions) Example of identity-based permission Example of resource-based permission Rob Can Read, Write, List On Resource : icon-designs icon-designs Rob: Read, Write, List Samantha: List Zoe: Read, List
- 10. IAM Policies Two types of identity-based policies in IAM
- • Managed policies (newer way)
- • Can be attached to multiple users, groups, and roles
- • AWS managed policies (created and managed by AWS)
- • Customer managed policies (created and managed by you) o Up to 5K per policy o Up to 5 versions • You can limit who can attach managed policies
- • Inline policies (the older way)
- • You create and embed directly in a single user, group, or role • Variable policy size (2K per user, 5K per group, 10K per role)
- 11. Live Demo 1.
- Create a new IAM user called Rob 2. Assign Rob a password 3. Enable MFA for Rob (Authy 2FA app: https://www.authy.com/app/mobile/) 4. Require password reset at next sign-in 5. Grant Rob administrative permissions over Amazon S3 by attaching an AWS managed policy i. Replace with a less permissive AWS managed policy ii. Replace with a customer managed policy Demo Time
- 12. Side bar SSH Keys: you can associate an SSH key with your IAM user and then use the SSH key to authenticate with AWS CodeCommit (a managed source control service) Credential Reports: You can generate and download a credential report that lists all IAM users in your account and the status of their various credentials, including passwords, access keys, and MFA devices. For passwords and access keys, the credential report shows how recently the password or access key has been used Example of retrieving Credential Report Example of associating SSH keys to IAM user
- 13. Side bar Trusted Advisor: your customized cloud expert! It helps you to observe best practices for the use of AWS by inspecting your AWS environment with an eye toward closing security gaps, saving money, and improving system performance and reliability. Example of identifying security gaps by using Trusted Advisor
- 14. IAM Groups What
- • Collection of IAM users
- • Specify and manage permissions for multiple users, centrally
- • E.g. group for all UX Designers
- • A group can contain many users, and a user can belong to multiple groups When
- • Easily manage permissions for multiple users AWS Account IAM Group: Administrators Akshay Andrea Arvind IAM Group: UX Designers Rob Rachel IAM Group: DevOps Akshay Andrew Lin Zoe Example of managing permission using groups
- 15. IAM Groups Why (Benefits)
- • Reduces the complexity of access management as number of users grow
- • Easy way to reassign permissions based on change in responsibility
- • Easy way to update permissions for multiple users
- • Reduces the opportunity for a user to accidently get excessive access Do
- • Create groups that relate to job functions
- • Attach policies to groups
- • Use managed policies to logically manage permissions
- • Manage group membership to assign permissions
- 16. Live Demo 1.
- Create a new IAM group called UXDesigners 2. Assign permissions to the IAM group 3. Create a new IAM user called Rachel 4. Add Rob and Rachel to the IAM group Demo Time
- 17. IAM Roles What
- • Another identity with permission policies that determine what the identity can and cannot do in AWS • Can be assumed by anyone who needs it; not uniquely associated with one person or application • Does not have credentials; access keys are created and provided dynamically When • Give cross-account access • Give access within an account • E.g. access for application running on Amazon EC2 • [Federation] Give access to identities defined outside AWS • E.g. access for identities maintained in your corporate IdP
- 18. Use IAM roles to share access Why (Benefits)
- • No need to share security credentials
- • No need to store long-term credentials
- • Control who has access Do
- • Use roles to delegate cross-account access
- • Use roles to delegate access within an account • Use roles to provide access for federated users
- 19. prod@example.com Acct ID: 111122223333 ddb-role { "Statement": [ { "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:DescribeTable", "dynamodb:ListTables" ], "Effect": "Allow", "Resource": "*“ }]} dev@example.com Acct ID: 123456789012 Authenticate with Rob’ access keys Get temporary security credentials for ddb-role Call AWS APIs using temporary security credentials of ddb-role { "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111122223333:role/ddb-role" }]} { "Statement": [ { "Effect":"Allow", "Principal":{"AWS":"123456789012"}, "Action":"sts:AssumeRole" }]} ddb-role trusts IAM users from the AWS account dev@example.com (123456789012) Permissions assigned to Rob granting him permission to assume ddb- role in account B IAM user: Rob Permissions assigned to ddb-role STS Use IAM roles for cross-account access
- 20. Use IAM roles for Amazon EC2 instances Why (Benefits)
- • Easy to manage access keys on EC2 instances
- • Automatic key rotation
- • AWS SDKs fully integrated
- • AWS CLI fully integrated Do
- • Use roles instead of long term credentials
- • Assign least privilege to the application
- 21. 1. Use Switch Role between two accounts 2. Launch an EC2 instance with a role Demo Time
- 22. Pop-up Loft Questions?
- 23. Pop-up Loft aws.amazon.com/activate Everything and Anything Startups Need to Get Started on AWS
sourec
https://www.slideshare.net/AmazonWebServices/aws-iam-introduction
https://www.whizlabs.com/blog/aws-identity-access-management-iam/ - prac
https://intellipaat.com/interview-question/amazon-aws-interview-questions/ - que
https://www.whizlabs.com/blog/aws-identity-access-management-iam/ - prac
https://intellipaat.com/interview-question/amazon-aws-interview-questions/ - que
No comments:
Post a Comment