AWS IAM – The Beginning of Everything…
AWS Identity and Access Management Service, known as AWS IAM, is nothing more than the service that we first have contact with when creating an account on Amazon Web Services, this is because, when we create an account, we also create the ROOT user, this being the user who will have permissions to perform any and all actions within the account created, He owns the account.
So I see it necessary to start our series of articles on AWS with this, AWS IAM, which is present in every “corner” from authentication to permissions of interactions with other AWS services and identity management, these being its three activities.
Speaking of authentication, we have a few ways to do it, remembering that every interaction you make with AWS is authenticated.
What are the types of authentication and credentials?
– Console (Browser) making use of Name and Password.
– API/CLI, programmatic keys (AccessKey, SecretKey) are used, and can have up to 2 active keys.
Note: There are other forms of authentication for applications, which we will address in the near future, but if you are anxious like me, we will deal with the service called Cognito.
AWS IAM allows you to create 3 types of identity objects, which are:
User, whether a human or an application, in the “identity” aspect of AWS Identity and Access Management (IAM) helps you with the question “Who is this user?”, often called authentication. IAM users are not separate accounts; they are users in your account. Each user can have their own password to access the AWS Management Console. You can also create an individual access key for each user so that the user can make programmatic requests to work with resources in your account.
IAM group is a set of IAM users, which allows you to specify permissions for similar types of users.
Example: Development group, in this contains developers who require similar permissions, permissions that differ from the Finance group.
Roles, focused on AWS services and External Access
Roles allow you to delegate access to users, applications, or services that you don’t normally have access to your Organization’s AWS resources…
Roles can be used in the following scenarios:
– An IAM user or role in the same or different AWS account that needs access provided by the role.
– Applications that run on EC2 and need to consume another AWS service.
– An AWS service that needs to call another service (e.g., a Lambda function that consumes AWS S3 objects).
– An external user authenticated by an identity provider service (IDP) compliant with SAML 2.0, OpenID connect, or a custom identity broker. (We’ll talk about IdP and federation already, but in case of anxiety, look for AWS IAM Identity Center, the former AWS SSO.)
Good Practices:
Password Policies, is a set of rules that establishes the type of password that the user can set. Yes, it’s that boring stop that prevents you from putting the name of the dog or the birthday of the mother-in-law, lol. (Use this)
Multifactor authentication (MFA) is an additional layer of security for accessing AWS services, with this authentication method, which consists of a user name, password, and the one-time use code of the MFA device. With this more than one factor of authentication and verified before access is granted, added another layer of security.
User ROOT, apply MFA to it, create other users for account management, containing permissions for such and store it in a safe, drawer, under the mattress and forget about it. Serious? Seriously, root user is of extreme power and the loss or leakage of this can cause you big, immense problems.
Let’s talk about Authorization?
So we know that having a user can access the AWS account, but what else happens?
logged in and ready I have access to everything ?
Not quite…
See, User → Authentication → Sends access request → Authorization (identity-based Policy Query) and allows or denies access to resources.
Well, as said the authorization is given through IAM policies (policy-ies), but calm, before talking directly about these policies, which are nothing more than documents where you say what you can and can not do, we need to talk about the three parts of the logic that defines what is in the policy and how the policy really works. These pieces make up the request context authenticated by IAM and authorized accordingly. So we have the main Entity, Action and Resource, think as subject, verb and object of a sentence, yes in that order.
Principal Entity (Principal):
Are the user, role, external user or application that sends the request and the policies associated with the main entity
Action:
What the main entity will be trying to do
Resource:
AWS resource object on which actions or operations will be performed
The following identity-based policy allows the implicit principal to list a single Amazon S3 bucket named example_bucket:
See that here we have a Principal, implicit because this is an identity-based policy, this is fixed to a user (Identity).
In an upcoming post, we’ll just talk about Policies, their types, best practices, Policy Evaluation Logic, and IAM Access Analyzer.
And in the beginning the policies were created.
IAM policies, their type and form of use
Access through identity-based policies
You manage access on AWS by creating policies and attaching them to IAM identities or AWS resources. An identity-based policy is an object in AWS that when associated with an IAM identity sets its permissions.
There are 3 types of identity-based policies
Managed by AWS
Customer Managed
Online
Types of policies
Identity-based
Also known as IAM policies, identity-based policies are managed, and inline policies attached to IAM identities (Users, user groups, or roles) deploy iam core permissions
Feature-based
These are inline policies attached to AWS resources. The most common examples of resource-based policing are Amazon S3 bucket policies and IAM role trust policies Resource-based policies grant permissions to the specific principal in the policy or account.
Permission Limit (Boundary)
Permission limit set defines the maximum permissions that an identity-based policy can grant to an entity.
E.g.: condition {stringEquals: {iam: PermissionBoundary: arn:AWS:iam::0–12:policy/<policy_name>}}
