Like everyone I have been learning public cloud lately. I figured I would start with AWS based on its ubiquity. Knowing that the best way to learn something is to teach it, I decided to start the Learning AWS series. Whenever I learn a new technology, I like to really hone in on the basics. So this post was born out of that idea.
IAM: Identity and Access Management
Above is a screenshot from the IAM console. Note the left column. These are the ideas that make up IAM in AWS.
1. Groups: Groups are a collection of users. AWS does not allow nesting of groups. Users can be members of multiple groups and this is how users get different permission policies. Groups do not have any permissions initially. Policies must first be applied to a group to grant permissions on AWS resources.
2. Users: Users are typical human user accounts but can also be service accounts. When used as service accounts or for REST/Query API access, a key ID and secret key will be used in place of a username/password. For example, you could embed the access key ID and secret key ID in software on a web server. This web server could then access AWS resources such as S3 via the account. For simple access to the management console, a username and password is sufficient. Each account whether service or user has a username, password, MFA option and a key ID /secret key option. There is a max number of accounts you can create. Users is not intended to be as a directory service. Like Groups, users also have no permissions by default.
3. Roles: Similar to Groups but not the same. Role can be assigned to more than users. Roles can be assigned to EC2 instances, for example. Instead of a service account embedded on a server as before, we now apply a role to the entire ec2 server instance and it is able to make S3 transactions without any proxy service account. The server itself has the permissions of the role instead of a user having the permissions. Also used for Federated accounts such as Microsoft Active Directory, etc.
AWS defines roles as follows:
“IAM roles are not associated with a specific user or group. Instead, trusted entities assume roles, such as IAM users, applications, or AWS services such as EC2.” source
Types of Roles:
a. AWS Service will call AWS resources on your behalf as mentioned above with the EC2 instance.
b. Another AWS account is cross account access between an identity provider account and an AWS account. It allows entities in other accounts to perform actions as the AWS account.
c. Web identity allows users federated by external web identity or OpenID Connect providers to assume this role to perform actions in your account. Providers such as Google and Facebook are nativity supported.
d. SAML 2.0 federation is similar to Web identity. It allows users that are federated with SAML 2.0 to assume this role to perform actions in your account.
Note: I pulled some of the wording above from the tool tips in the IAM console.
4. Policies: Policies are used to grant access. Policies are created apart from Users, Groups or Roles. They are applied to Users, Groups or Roles. Permissions are JSON based statements. JSON is vital for AWS administrators. IAM JSON statements elements are as follows: Version, Statement, Sid, Effect, Principal, Action, Resource and Condition. For now I will only be covering Version, Statement, Effect, Action and Resource. HERE is a list of all the IAM JSON policy elements including those I chose not to cover in this post.
Version, Statement, Effect, Action and Resource
I found a pre-defined S3 read-only access policy from AWS and copied it below. I did update the Resource line to be specific to my S3 bucket but made no other modifications. Lets walk through its elements.
a. Version: This defines the version of the policy language. Think JSON version. The current version is 2012-10-17, so use that if you attempt to write a policy from scratch.
b. Statement: This is the main body of the policy. Statements have the Effect, Action and Resource elements which actually make up the permissions. You can actually have an array of statements in a policy, but my example only has one.
c. Effect: This is the allow or deny option of the rule.
d. Action: This is the “What” of the rule. The action has a amazon service name (ASN): action syntax. For example Action could be s3:List*. This would allow the entity who has had the policy applied to be able to list all of the content in my s3 bucket. You can see in my example below this policy defines Get* and List*, in effect this allows us to get information about anything in the S3 bucket named mybucket without being able to modify its contents. The words following the service, such as “list”, are specific to that resource and are predefined. It is the actions AWS says you can do to the resource. (Get, List, Put, Etc.) Here is S3’s actions for example.
e. Resource: I think about resources as an instance of the service. Resources follow the Amazon Resource Name scheme. In essence a resource is an instance of an amazon service such as S3 referenced by a specific naming scheme. For example a bucket in S3 might look like this, arn:aws:s3:::mybucket. So its not S3 in general which would be considered a service, but instead the resource is mybucket. ARN is a blog post all on its own. For now I’m going to leave you with this link to investigate further.
5. Identity providers: This allows federated identity with providers that use SAML or OpenID. Active directory integration and management is done using Directory Service as separate AWS service.
6. Account Settings: Here you set password complexity for user accounts and define which regions can request temporary credentials.
- Users go in Groups.
- Everything else gets assigned a Role.
- Policies define permissions and are applied to Users, Groups and Roles.
- Effects allow you to allow or deny an action.
- Services have actions that can “happen” to them.
- Resources are instances of a service and provide scope for a policy.