IAM allow Admins to manage users and their level of access to AWS resources. IAM gives centralized access to manage authentication and authorization. The ‘I’ in IAM refers to authentication (as in identity) and ‘A’ in IAM refers to authorization (as in access). IAM can act on Users and Groups, can create or use Policy documents and define Roles. IAM operates Globally since it is not bound to any specific region. Similarly, the users, groups, roles and policies IAM manages are all global in nature and not bound to any specific Region. IAM can integrate with users directory service and can create a single sign-on environment. IAM can give Principals (users/groups) Console access (Portal) or Programmatic access (API). For Console access, we can also setup MFA (Multi Factor Authentication) in IAM, which provides additional security for the account.
Users accessing AWS resources programmatically needs to provide Access Key ID and Secret Key instead of UserId/Passwd. Password policies can be defined that control password behavior, e.g. number of characters, number of special characters etc. IAM portal can be used to define and manage policies. IAM portal features an editor to manage both, Identity and Resource based policies. The number in the IAM sign-in link is the AWS account number. The sign-in link can be customized to add an account name alias, instead of using the long account number.
Policies: A policy is a JSON document that lists various actions (and categorize them between “Action” (doable) or “NotAction” (not doable)) on any given resource (identified by “Resource” (s3 bucket) or excluded using “NotResource” (vpc34) or specified as wildcard ” * “) for specified users/groups (listed as “Principal” or excluded using “NotPrincipal“). The Policy defines selected actions to have effect (of either “Allow” or “Deny“). Policy definition has language versions associated with them (e.g. “2012-10-17”). Optionally, Policies can have Condition blocks that uses constructs (like “DateGreaterThan” or “IpAddress“), to match against values coming in request. When a condition is associated with a policy, then the condition must be satisfied for the policy to be in effect. Policies can be assigned to Users/Groups/Roles.
Policies encloses permissions that are granted or revoked. When permissions are directly associated to a user, group or role, then they are referred as “Inline Policies”. Unlike that, when permissions are formally listed and defined as allowed/denied and specified set of resources in a JSON language, then they are referred as “Managed Policies”. We can define and associate managed/inline policies to resource, like an S3 Bucket (Resource Based Policy) or we can associate a non-managed policy to a group, like- California_S3_Users (Identity Based Policy).
There are some built-in “AWS Managed Policies” that AWS has defined, like- Power User (Admin minus IAM access), AmazonS3FullAccess (Full access to all S3 buckets via Console), AWSLambdaExecute (Put/Get to S3 plus CloudWatchLogs full access) etc. The managed policies that users define are referred as “Customer Managed Policy” and can be created using Policy Generator, or by copying an existing AWS managed policy or manually step-by-step in a JSON editor.
Roles: Roles are entities similar to a User, without any associated credentials but with permissions and policies applied. When a role is assigned to any user, temporary credentials are generated implicitly and assigned to the user. Roles can be assigned to users, applications, services, other AWS account users or even OpenID providers, like- Google or Facebook. Roles can be assigned to AWS services as well, and thats the only way to grant permissions/policies to AWS services. When roles are assigned to Principals, they gain temporary permissions which are removed when the role is unassigned from them.
Multi Factor Authentication: On the IAM dashboard, click on “MFA” to start configuring MFA on the Root account. After clicking the “Manage MFA” button, an IAM user can choose between a virtual or a hardware MFA device. The virtual MFA device is actually an application that can be installed on a Smartphone, Tablet, PC or similar device. For every IAM user, it is possible to configure MFA. For root user, there is an option readily available on IAM dashboard, but for non-root users, either the root user can configure MFA for them or root user can allow other users to setup MFA themselves.
New users, by default have NO permission. Users can obtain permissions either by direct assignment, or via group permissions, or via policy/role assignment. Passwords or key/secret are generated only while user creation and are shown only once on the console to allow download of the same. If the credentials are not downloaded or lost, they need to be generated again and previous credentials need to be disabled.
Every User/Group/Policy/Role has a unique ARN (Amazon Resource Name) associated with it.
.
Vipul Pathak 
Leave a comment