AWS Identity management (IAM) & AWS Organizations services help effectively manage access to AWS resources, controlled via a master / management account; note that billing also known as master also known as management account is different from an administrator (admin) account;
AWS Organizations help define & manage sub OR child account linked to master / management account; AWS billing links the cost from each child account, summed up to the master account; volume discounts are also applied at the master account - with aggregated usage;
Resource tagging - helps easily find billing by resources;
Points related to master accounts:
- create child accounts, send an invite for child accounts to link with master account;
- assume roles using STS cross-account capability;
- use cloud formation stack sets to create IAM roles in target accounts;
- create organization division-specific accounts - managed centrally;
- automate account creation process, integrate with AWS SSO (single sign-on)
AWS control tower used for multi-account billing strategy is covered here
Environment specific accounts - for better access control, environment specific (dev / test / uat accounts separated from prod instance) accounts can be created, with corresponding resource allocation limits, compliance controls;
Use of organizations, resource groups & tagging for consolidated billing:
- keep resources in a region which is cheaper, reduce cost of data transfer; manage your assets with tagging; tags usage:
- tags for AWS organization & resource groups
- tags for cost allocation
- automation
- access control
- operation support
Resource groups - grouping of AWS resources by tags; custom consoles to consolidate metrics & alarms; common resource groups - environments, project resources, collection of key business processes, resources allocated to business groups or cost centers; resource groups supports 2 types of queries - tag based & AWS cloud formation stack based;
------------------------------------------------------------------------------------------------------------------------
Service control policies (SCP) - whitelist / blacklist IAM actions are applied via SCP; can be applied at root / OU / account level;
- SCP is applied to all users & role of the account - inclusive of root;
- SCP does not affect master accounts;
- SCP does not affect service-linked roles; roles linked to services enable other AWS services to integrate with AWS organizations - hence not restricted by SCPs;
- by default - all access is denied; an explicit allow statement in SCP grants access;
- allows having resources launched in the same subnet;
- resources shared within same AWS organization;
- cannot share security groups & default VPC;
- participants cannot view / modify / delete resources belonging to other participants or owner;
------------------------------------------------------------------------------------------------------------------------
IAM policies - STS (simple token service) is used to provide short-term access to users; policies are configured - linked with associated roles for long-term access to AWS resources; policies can also be assigned to IAM groups;
Roles - policies are created & associated with AWS roles; roles in turn can be associated with services such as EC2 instances, S3 buckets / objects, RDS data base services, Dynamo DB / NO SQL data base services, SQS / SNS service instances, etc. Roles can apply cross accounts as well, recommended, easier & cleaner to securely grant / revoke access to AWS services;
When assuming a role, original permissions are given up when assuming the role; however, using resource-based policy, principal doesn't give up any permissions;
- EC2 instance roles can be assigned with one role per instance;
- Service roles can be assigned for services such as API Gateway, Code Deploy, etc.
- Cross account roles - are helpful to control access across accounts, without sharing user credentials;
Policies - can be AWS-managed, resource-based, customer-managed OR inline policies; each policy is a JSON document consisting of RACE constructs [Resources, Action, Conditions & Effect]; principle of least privileges is the best practice when applied to IAM policies & roles - to restrict access to the required resources, as deemed necessary to serve the purpose;
With policies:
- by default, no access is allowed to AWS resources;
- explicit allow - grants access to authorized users / roles;
- explicit deny takes highest precedence;
- does not propagate parent-level access to child nodes;
Related examples for IAM policies are here; sections inside the policies are - Effect, Action, Conditions & Resource; Policy variables can also be defined in addition;
Power user access - is one-level below admin access...can be associated with effect NOT ACTION, instead of DENY - to avoid explicit deny; used when access has to be restricted for certain components while allowed to perform other actions;
Use Access advisor - to examine the permissions granted & capture trail of last accessed; Use Access analyzer to determine resources shared with external entities;
Conditions in IAM policies - consists of an operator, key & value;
- condition operators are defined to work with strings, numeric values, boolean, date, IP address, ARN & 'null' conditions
- condition key specifies the variable name to compare and
- condition value specifies the variable value to compare against
- condition operators such as 'String like', 'String equals', 'IpAddress', 'Date equals', 'Numeric not equals', etc. can be linked on the IAM policy
- condition operators can be assigned to work with ARN (amazon resource names) - to restrict VPC access [ARN equals, ARN like]
- default variables e.g. ${aws:username}
- AWS specific variables: e.g. aws:currentTime, aws:SecureTransport; aws:userId...
- service specific variables - e.g. s3:prefix, sns:protocol...
- tag-based - e.g. iam:ResourceTag/key-name...
------------------------------------------------------------------------------------------------------------------------
STS (security token service) - define an IAM role & configure principals which can access the IAM role; use STS to retrieve credentials & impersonate the IAM role; credentials are valid between 15-60 minutes; STS is used when:
- temporary credentials to onboard new users on AWS
- access to external users authenticated via identity federation
- cross-account access, when one or more accounts are linked with single owner
- user access to accounts owned by third-parties
IAM access analyzer - can be used to find out resources that are exposed, when providing access to third party users - outside the zone of trust; To grant access to 3rd party users, there are 2 steps:
- create 3rd party AWS account ID
- create an external ID [secret shared between account owner & 3rd party who needs access]
------------------------------------------------------------------------------------------------------------------------
Federated identity access - is where the user gets authenticated from an external identity provider, can be one of the following:
- Single sign-on (SSO), SAML 2.0;
- non-SAML via Microsoft AD;
- custom identity broker;
- web-identity federation using Amazon Cognito OR third-party identity provider;
- support for anonymous users;
- support for MFA;
- data synchronization across devices;
- Simple AD - works stand-alone, simplest option & cost effective to manage user accounts & access; AD is created on AWS & does not interface with directory services on-premise / in-house;
- AD connector - AWS provides AD connector as a proxy to AD hosted on-premise; all requests to authenticate on AWS are re-directed via AWS AD connector into AD on-premise server;
- AWS-managed Microsoft AD:
- here, 2 sets of users maintained - one on AWS cloud and another on the on-premise AD server;
- AWS-managed AD trusts the AD hosted on-premise;
- hence, authenticated requests from users on-premise get access to AWS resources and authenticated requests from users on cloud get access to on-premise resources;
No comments:
Post a Comment