IAM Roles

By Ashwin Venugopal -

 







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

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more