IAM Roles

 







Roles Terms & Concepts

Role

It's an IAM identity created in your account with some specific permissions, and although IAM roles are similar to an IAM user in some aspects, they are always intended to be assumable by anyone who needs it instead of being uniquely associated with one person. Roles can be used by following:
  1. An IAM user in the same AWS account as the role.
  2. An IAM user in a different AWS account than the role.
  3. A web service offered by AWS like Amazon Elastic Compute Cloud (EC2).
  4. An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker.

AWS Service Role

It's a role assumed by any service in order to perform actions in your account on your behalf, hence, you have to always define a role for the service to assume while setting-up some AWS service environments.

AWS Service Role for an EC2 Instance

This is a special type of role that an application running on an Amazon EC2 instance can easily assume to perform actions in your account. This role is always assigned to the EC2 instance when it's launched.

AWS Service Linked Roles

It's a unique type of service role linked directly with an AWS service and they are generally predefined by the service having all the required permissions needed by a service to call the other AWS services on your behalf.

Role Chaining

If you use a role to assume a second role via AWS CLI or AWS API, then it is called role chaining. However, it also limits your AWS CLI or AWS API role session to a maximum of one hour.

Delegation

If you would like to grant permissions to others to allow access to your resources, then, delegation can help you in setting up trust between the two accounts. The first one owns the resource (i.e. the trusting account) and second one contains the users in need of access to that resource (i.e. trusted account) and they can be any one of the following:
  1. The same account.
  2. Separate accounts that are both under your organization's control.
  3. Two accounts owned by different organizations.

Federation

It's related to the creation of a trust relationship between an external identity provider and AWS and whenever you use OIDC and SAML 2.0 to configure a trust relationship between these two, the user is assigned to an IAM role. The user also receives temporary credentials to access your AWS resources.

Federated User

You can also use the existing identities from AWS Directory Service, your enterprise user directory, or a web identity provider (instead of creating an IAM user), also known as federated users.

Trust Policy

It's a JSON policy document defining the principals that you trust to assume the role. A role trust policy is a required resource-based policy attached with a role in IAM.

Permissions Policy

This document is in JSON format, and defines the actions as well as resources the roles can use. It's written according to the rules of the IAM policy language.

Permissions Boundary

As the name suggests, it's an advanced feature limiting the maximum permissions that an identity-based policy can grant to a role. However, a permissions boundary is not applied to a service-linked role.

Principal

It can perform actions and access resources in AWS. It can be an AWS account root user, an IAM user, or a role. In order to access a resource, the permissions can be granted in one of the two ways:
  1. You can attach a permissions policy to a user (directly, or indirectly through a group) or to a role.
  2. The services supporting resource-based policies can help in identifying the principal via principal element of a policy attached to the resource.

Role for Cross-account Access

 It's a role that can grant access to a resource in one account to a trusted principal in a different account.




































Comments

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

Work with String Data Using KQL Statements

Threat Hunting in Microsoft Sentinel (part 1)