IAM: Users & Groups
- IAM = Identity and Access Management, Global service.
- It is a global service because in IAM, we are going to create our users and assign them to group.
- So, we've already used IAM without knowing, when we created an account, we created a root accounts, and has been created by default.
- Root account created by default, shouldn’t be used, or shared.
- Users are people within your organization and can be grouped.
- Groups only contain users, not other groups.
- Users don’t have to belong to a group, and user can belong to multiple groups.
You have Alice, Bob, Charles, David, Edward and Fred so all these people are in your organization.
- Now Alice, Bob, and Charles they work together. They're all developers.
- So, we're going to create a group called the group developers who regrouping Alice, Bob, and Charles.
- And it turns out that David and Edward also work together. So, we're going to create an operations group.
- Now we have two groups within IAM.
- Now groups can only contain users, not other groups.
- So, this is something very important to understand. Groups only contain users.
- Now, some users don't have to belong to a group. For example, Fred right here is alone, he does not correspond to any group. That is not best practice.
- But it is something you can do in AWS.
- And also, a user can belong to multiple groups.
- That means that for example, if you know that Charles and David worked together, and they're part of your audit team, you can create a third group with Charles and David.
- And as you can see, now, in this example, Charles and David are part of two different groups.
- So, this is the possible configurations for IAM.
IAM: Permissions
- So why do we create users and why do we create groups?
- Well, because we want to allow them to use our AWS accounts and to allow them to do so, we have to give them permissions.
- So, users or groups can be assigned what's called a JSON document. I'll show you right now what it means called a policy, an IAM policy.
- So, it looks just like this.
- So, in this example, we can see that we allow people to use the EC2 to service and do describe on it, to use the elastic load balancing service and to describe on it and to use CloudWatch.
- We are allowing our users to use some services in AWS. So, these policies will help us define permissions of our users.
- And so, in AWS, you don't allow everyone to do everything that would be catastrophic, because a new user could basically launch so many services and they will cost you a lot of money or would be valid for security.
- So, in AWS, you apply a principle called the least privilege principle.
- So, you don't give more permissions than a user needs.
- Okay, so if a user just needs access to three services, just create a permission for that user.
- Consists of
- Version: policy language version, always include “2012-10-17”
- Id: an identifier for the policy (optional)
- Statement: one or more individual statements (required)
- Statements consists of
- Sid: an identifier for the statement (optional)
- Effect: whether the statement allows or denies access (Allow, Deny)
- Principal: account/user/role to which this policy applied to
- Action: list of actions this policy allows or denies
- Resource: list of resources to which the actions applied to
- Condition: conditions for when this policy is in effect (optional)
IAM – Password Policy
- Strong passwords = higher security for your account
- In AWS, you can setup a password policy:
- Set a minimum password length
- Require specific character types:
- including uppercase letters
- lowercase letters
- numbers
- non-alphanumeric characters
- Allow all IAM users to change their own passwords
- Require users to change their password after some time (password expiration)
- Prevent password re-use
Multi Factor Authentication - MFA
- Users have access to your account and can possibly change configurations or delete resources in your AWS account
- You want to protect your Root Accounts and IAM users
- MFA = password you know + security device you own
- Main benefit of MFA:
- if a password is stolen or hacked, the account is not compromised
MFA devices options in AWS
Virtual MFA device
- It has Google Authenticator, which will be just working on one phone at a time
- Other is Authy which is multi-device. You can use it on my computer and on my phones. So, for Authy you have support for multiple tokens on a single device.
Universal 2nd Factor or U2F Security Key
- This is a physical device
- For example, a YubiKey by Yubico and Yubico is a 3rd party to AWS.
- So, this YubiKey supports multiple roots and IAM users using a single security
Then your other options, you have a Hardware Key Fob MFA
device, for example this one provided by Gemalto which is also a third party to
AWS, and finally if you are using the cloud of the government in the US, the
AWS GovCloud then you have a special Key Fob, that looks like this, that is
provided by SurePassID which is also a 3rd party.
How can users access AWS?
To access AWS, you have three
options:
- AWS Management Console (protected by password + MFA)
- AWS Command Line Interface (CLI): protected by access keys
- This is something we will set up on our computer, and this is protected by access keys, and access keys our credentials that will allow us to access AWS from our terminal.
- AWS Software Developer Kit (SDK) - for code: protected by access keys
- This is used whenever you want to call APIs from AWS from within your application code. And again, these will be protected by the exact same access keys.
Users manage their own access keys
Access Keys are secret, just like a password. Don’t share them
Access Key ID is just like username
Secret Access Key is just like password
Example (Fake) Access Keys
- Access key ID: AKIASK4E37PV4983d6C
- Secret Access Key: AZPN3zojWozWCndIjhB0Unh8239a1bzbzO5fqqkZq
- Remember: don’t share your access keys
What’s the AWS CLI?
A tool that enables you to
interact with AWS services using commands in your command-line shell
Direct access to the public APIs
of AWS services
You can develop scripts to manage
your resources
The CLI is open source, you can
find all the source code on GitHub: https://github.com/aws/aws-cli
Alternative to using AWS
Management Console
What’s the AWS SDK?
- AWS Software Development Kit (AWS SDK
- Language-specific APIs (set of libraries)
- Enables you to access and manage AWS services programmatically
- Embedded within your application: SDK is not something that you use within your terminal, it is something that you embedded within your application that you have to code. So, your application will have the AWS SDK from within them.
- Supports
- SDKs (JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++)
- Mobile SDKs (Android, iOS, …)
- IoT Device SDKs (Embedded C, Arduino, …)
- Example: AWS CLI is built on AWS SDK for Python
Let talk to you about an alternative to using the terminal to issue commands against AWS, and this is AWS Cloudshell.
What is AWS CloudShell?
AWS CloudShell is a browser-based, pre-authenticated shell
that you can launch directly from the AWS Management Console. You can run AWS
CLI commands against AWS services using your preferred shell, such as Bash,
PowerShell, or Z shell. And you can do this without needing to download or
install command line tools.
When you launch AWS CloudShell, a compute environment that's
based on Amazon Linux 2 is created. Within this environment, you can access an
extensive range of pre-installed development tools, options for uploading and
downloading files, and file storage that persists between sessions.
AWS CloudShell features
- AWS Command Line Interface
- Shells and development tools: With the shell that's created for AWS CloudShell sessions, you can switch seamlessly between your preferred command-line shells.
- Persistent storage: With AWS CloudShell, you can use up to 1 GB of persistent storage for each AWS Region at no additional cost.
- Security
- Customization options: You can customize your AWS CloudShell experience by changing screen layouts (multiple tabs), text sizes, and light/dark interface themes.
- Session restores: The session restore functionality restores sessions that you were running across single or multiple browser tabs in the CloudShell terminal. If you refresh or reopen recently closed browser tabs, this functionality resumes the session until the shell is stopped because of inactive session. To continue using your CloudShell session, press any key within the terminal window.
Bottom of the line, cloud
shell is only available in some regions. So maybe try to choose one of the
regions where cloud shell is available.
IAM Roles for Services
- Some AWS service will need to perform actions on your behalf
- To do so, we will assign permissions to AWS services with IAM Roles
- As some AWS services that we'll be launching will need to perform actions on our behalf, on our account. And for this to do these actions, they're just like users, they will need some kind of permissions. So, we need to assign permissions to AWS services and to do so, we're going to create what's called an IAM Role. So, these IAM role will be just like a user, but they are intended to be used not by physical people, but instead they will be used by AWS services.
For example, we are going to create, an EC2 Instance.
- An EC2 Instance is just like a virtual server.
- But so, this EC2 Instance may want to perform some actions on AWS and to do so, we need to give permissions to our EC2 Instance.
- To do so, we're going to create an IAM Role and together they're going to make one entity.
- And together, once the EC2 Instance is trying to access some information from AWS, then it will use the IAM Role.
- And if the permission assigned to the IAM Role is correct, then we're going to get access to the call we're trying to make.
Common roles:
- EC2 Instance Roles
- Lambda Function Roles
- Roles for CloudFormation
IAM Security Tools
- IAM Credentials Report (account-level): A report that lists all your account's users and the status of their various credentials
- IAM Access Advisor (user-level)
- Access advisor shows the service permissions granted to a user and when those services were last accessed.
- You can use this information to revise your policies.
- This will be very helpful because we are talking already about the principle of least privilege, and so using this tool, we're able to see which permissions are not used and reduce the permission a user can get to be inline with the principle of least privilege.
IAM Guidelines & Best Practices
- Don’t use the root account except for AWS account setup
- One physical user = One AWS user
- Assign users to groups and assign permissions to groups
- Create a strong password policy
- Use and enforce the use of Multi Factor Authentication (MFA)
- Create and use Roles for giving permissions to AWS services
- Use Access Keys for Programmatic Access (CLI / SDK)
- Audit permissions of your account with the IAM Credentials Report
- Never share IAM users & Access Keys
Shared Responsibility Model for IAM
Summary
- Users: mapped to a physical user, has a password for AWS Console
- Groups: contains users only
- Policies: JSON document that outlines permissions for users or groups
- Roles: for EC2 instances or AWS services
- Security: MFA + Password Policy
- AWS CLI: manage your AWS services using the command-line
- AWS SDK: manage your AWS services using a programming language
- Access Keys: access AWS using the CLI or SDK
- Audit: IAM Credential Reports & IAM Access Advisor
No comments:
Post a Comment