AWS Organizations, IAM

1. Active Directory
1. AD Connector is a directory gateway with which you can redirect directory requests to your on-premises Microsoft Active Directory without caching any information in the cloud. AD Connector comes in two sizes, small and large. You can spread application loads across multiple AD Connectors to scale to your performance needs. AD Connector is your best choice when you want to use your existing on-premises directory with AWS services.
2. AD Connectors and your on-premises AD domains have a 1-to-1 relationship. 
3. Your end users and IT administrators can use their existing corporate credentials to log on to AWS applications such as WorkSpaces, Amazon WorkDocs, or Amazon WorkMail.
4. Simple AD is a standalone managed directory. Small - Supports up to 500 users, Large - Supports up to 5,000 users. Simple AD does not support features such as multi-factor authentication (MFA), trust relationships with other domains. 
5. AWS Directory Service lets you run Microsoft Active Directory (AD) as a managed service.  best choice if you have more than 5,000 users.
6. When you select and launch this directory type, it is created as a highly available pair of domain controllers connected to your virtual private cloud (VPC). The domain controllers run in different Availability Zones in a Region of your choice. you can use it for a variety of tasks:
1. Manage users and groups
2. Provide single sign-on to applications and services
3. Create and apply group policy
4. enable multi-factor authentication 
2. Active Directory
1. AD concepts
1. A forest is a logical construct used by Active Directory to group one or more domains. The domains then store objects for user or groups, and provide authentication services. Managed AD contains only 1 domain while On-premise may consists of one or more domains.
2. In a one-way trust relationship, the trusting domain makes its resources available to the trusted domain. 
3. A two-way trust relationship consists of two one-way trusts in opposite directions. By default in Active Directory, all domains in a forest trust each other with two-way transitive trust relationships.  Each domain is configured as both the Accounts domain and the Resource domain, so users in either domain can access resources in the other domain.
4. AD requires a DNS server - AWS recommends leveraging VPC+2 DNS for the purpose. Alternatively we can have a DNS server in a public subnet or NAT gateway in public subnet is another alternative.
2. Self Managed on EC2
3. AWS Managed MS AD - AWS takes care of isolating domain controllers of customers, encrypting the EBS vol that contain the AD, taking daily snapshots, automatically applying patches, maintain availability.
1. We can have domain controller with user and resource objects in On-premise. In such case the domain controllers from AWS ( 1 in each AZ) will have continuous replication with on-premise. Hence we should have consistent good connectivity with the data centers. Supports LDAPS and need to be enabled.
2. Alternate model we can establish a One way trust from the AWS domain controller to the On-premise active directory. There is no need for replication in such case. As the resource objects will be in AWS controllers.
3. Other  Directory Types - AD connector and Cognito User pools.
3. Active Directory and SSO
1. AWS Single Sign-On is a cloud-based service that simplifies how you manage SSO access to AWS accounts and business applications. You can control SSO access and user permissions across all your AWS accounts in AWS Organizations. Also, AWS SSO offers a user portal where your users can find all their assigned AWS accounts, business applications, and custom applications in one place. AWS SSO supports single sign-on to business applications through web browsers only -does not support  native mobile and desktop applications.
2. AWS SSO has integration with Microsoft AD through the AWS Directory Service. This means your employees can sign in to your AWS SSO user portal using their corporate Active Directory credentials. To grant Active Directory users access to accounts and applications, you simply add them to the appropriate Active Directory groups. For example, you can grant the DevOps group SSO access to your production AWS accounts. Users added to the DevOps group are then granted SSO access to these AWS accounts automatically. This automation makes it easy to onboard new users and gives existing users access to new accounts and applications quickly.
3. You can configure one and two-way external and forest trust relationships between your AWS Directory Service for Microsoft Active Directory and on-premises directories, as well as between multiple AWS Managed Microsoft AD directories in the AWS cloud. AWS Managed Microsoft AD supports all three trust relationship directions: Incoming, Outgoing, and Two-way (Bi-directional). AWS Managed Microsoft AD supports both external and forest trusts.
4. Users in your self-managed Active Directory (AD) can also have SSO access to AWS accounts and cloud applications in the AWS SSO user portal. To do that, AWS Directory Service has the following two options available:
1. Create a two-way trust relationship – When two-way trust relationships are created between AWS Managed Microsoft AD and a self-managed AD, users in your self-managed AD can sign in with their corporate credentials to various AWS services and business applications. One-way trusts do not work with AWS SSO.
2. Create an AD Connector – AD Connector is a directory gateway that can redirect directory requests to your self-managed AD without caching any information in the cloud.
5. Users, Groups, Permission Sets can be created using SSO. And such users can use the SSO URL to view the list of apps which they are enabled. This can be used to provide say a temp access to an external auditor or say Codepipeline access for a developer. Permission set comes with preconfigured admin rules, custom rules can also be defined. This way we can manage users centrally - by accessing through the Control Tower - Users and Access menu.
6. Allow On-Premise AD to be used
1. Before you can use SAML 2.0-based federation, you must configure your organization’s IdP and your AWS account to trust each other. 
2. Inside your organization, you must have an IdP that supports SAML 2.0.
3. In your organization’s IdP, you define assertions that map users or groups in your organization to the IAM roles. 
4. The role or roles that you create in IAM define what federated users from your organization are allowed to do in AWS. 
5. When you create the trust policy for the role, you specify the SAML provider that you created earlier as the Principal.
6. You can additionally scope the trust policy with a Condition element to allow only users that match certain SAML attributes to access the role.
7. The client when calling the STS AssumeRoleWithSAML API needs to pass ARN of the SAML provider, the ARN of the created IAM role, and SAMS assertion from the IdP.
7. SSO can have only one IdP Source - either SSO (users directly created), AD, or external AD. 
4. AWS Organization
1. After you create an Organization and verify that you own the email address associated with the master account, you can invite existing AWS accounts to join your organization. When you invite an account, AWS Organizations sends an invitation to the account owner, who decides whether to accept or decline the invitation. 
2. When an invited account joins your organization, you do not automatically have full administrator control over the account, unlike created accounts. If you want the master account to have full administrative control over an invited member account, you must create the  OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
3. SCP - An SCP defines a guardrail, or sets limits, on the actions that the account’s administrator can delegate to the IAM users and roles in the affected accounts. The administrator must still attach identity-based or resource-based policies to IAM users or roles, or to the resources in your accounts to actually grant permissions.
1. SCPs are available only in an organization that has all features enabled.
2. SCPs affect all users and roles in attached accounts, including the root user.
3. SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can’t be restricted by SCPs.
4. If an action is blocked by a Deny statement, then all OUs and accounts affected by that SCP are denied access to that action. An SCP at a lower level can't add a permission after it is blocked by an SCP at a higher level. SCPs can only filter; they never add permissions
5. FullAWSAccess SCP overrides the default implicit deny, and explicitly allows all permissions to flow down from the root to every account, unless you explicitly deny a permission with an additional SCP.
6. SCPs do not work to restrict any users or roles in the management account.

4. AWS Resource Access Manager (AWS RAM) enables you to share specified AWS resources that you own with other AWS accounts. To enable trusted access with AWS Organizations:

   1. From the AWS RAM CLI, use the enable-sharing-with-aws-organizations command.
   2. Name of the IAM service-linked role that can be created in accounts when trusted access is enabled: AWSResourceAccessManagerServiceRolePolicy.
   3. When you enable access, the trusted service can create an IAM role called a service-linked role in every account in your organization. That role has a permissions policy that allows the trusted service to do the tasks that are described in that service’s documentation. 
5. When an invited account joins your organization, you do not automatically have full administrator control over the account, unlike created accounts. If you want the master account to have full administrative control over an invited member account, you must create the  OrganizationAccountAccessRole IAM role in the member account and grant permission to the master account to assume the role.
6. Even though “All Features” is enabled by default, this will be overridden if you enable only the “Consolidated Billing” feature. This means that you cannot use the SCP to your member AWS accounts anymore. You need to enable “All features” on the AWS Organization to be able to create and apply SCP for each subsidiary.
7. The master account of an organization can turn off Reserved Instance (RI) sharing for member accounts in that organization. This means that Reserved Instances are not shared between that member account and other member accounts. You can change this preference multiple times. Each estimated bill is computed using the last set of preferences. However, take note that turning off Reserved Instance sharing can result in a higher monthly bill.
5. Tag Management
1. Tags are added when you create the resource however you can also add tags to multiple, supported resources at once by using Tag Editor. 
2.  A resource can have up to 50 user-applied tags. 
3. You can add tags to resources when you create the resource. 
4. To add tags to—or edit or delete tags of—multiple resources at once, use Tag Editor. 
5. AWS provides two types of cost allocation tags, AWS generated tags and user-defined tags. 
6. You must activate both (using the Billing and Cost Management console for cost allocation tracking) types of tags separately before they can appear in Cost Explorer or on a cost allocation report.
7. You can then use the tags on your cost allocation report to track your AWS costs. Tags are not applied to resources that were created before the tags were created.
8. The SCP rules will enforce the company tagging policy by preventing users from creating resources that do not have the appropriate tags. 
9. you can use the CloudFormation Resource Tags property to apply tags to certain resource types upon creation.
10. When you create IAM policies, you can specify resource-level permissions, which include specific permissions for creating and deleting tags. In addition, you can include condition keys, such as aws:RequestTag and aws:TagKeys, which will prevent resources from being created if specific tags or tag values are not present.
6. Cost Planning
1. one-time charges and refunds are not included in the billing metrics delivered to Amazon CloudWatch by Billing.
2. Standard Reserved instances - 1 or 3 year commitment for cost savings - OS/Region/Instance Family/Size/Tenancy cannot be changed
3. Convertible RI - Instance type/OS can be changed (involves work)  - Allows changing from No-Upfront to All-Upfront.
4. EC2 Savings plan - Choose instance type and region alone - Applies to ECS, EKS and EC2. OS can be changed.  OS/Region/Size/Tenancy - Need not be considered.
5. Compute savings plan - Commit for $ spend alone - Applies to Fargate,ECS, EKS and EC2 also.  Can be in any region. OS can be changed. Once committed cannot be modified.
6. Savings plan and RI apply first to the account which purchased it. Purchase this in production account. Also RI discount will be addressed first and Savings plan later.
7. There is no direct capacity reservation for savings plan for EC2. However on-demand capacity reservations can be used to reserve a combination of RI and savings plan.
8. Cost explorer -Review savings plan and recommendations - 

 Authentication, Permission Management,  Policies

• IAM
1. PowerUserAccess = AdministrativeAccess - IAM
2. IAM user cannot be added to an IAM group in a different account.
3.  a role cannot grant access to resources in another account
4. AWS managed policies for job functions are designed to closely align to common job functions in the IT industry. You can use these policies to easily grant the permissions needed to carry out the tasks expected of someone in a specific job function. These policies consolidate permissions for many services into a single policy that’s easier to work with than having permissions scattered across many policies.
1. AdministratorAccess if you want to provision full access to a specific IAM User. This will enable the user to delegate permissions to every service and resource in AWS as this policy grants all actions for all AWS services and for all resources in the account.
2. PowerUserAccess if you have users who perform application development tasks. This policy will enable them to create and configure resources and services except AWS Identity and Access Management and AWS Organizations.  It also grants Organizations permissions to view information about the user’s organization, including the master account email and organization limitations.
5. At times, you need to give third party access to your AWS resources (delegate access). One important aspect of this scenario is the External ID, optional information that you can use in an IAM role trust policy to designate who can assume the role.
1. To use an external ID, update a role trust policy with the external ID of your choice. Then, when someone uses the AWS CLI or AWS API to assume that role, they must provide the external ID.
2. Do not give external entities access to an IAM user and its long-term credentials in your AWS account. Instead, use an IAM role and its temporary security credentials. 
3. You can use an IAM role to establish a trusted relationship between your AWS account and the external entities account. After this relationship is established, a member of the external entities account can call the AWS STS AssumeRole API to obtain temporary security credentials. The external entities members can then use the credentials to access AWS resources in your account.
• The two policies that you attach to an IAM role are the access policy and the trust policy.  Trust policies define which entities can assume the role. You can associate only one trust policy with a role.
• Remember that adding an account to the trust policy of a role is only half of establishing the trust relationship. By default, no users in the trusted accounts can assume the role until the administrator for that account grants the users the permission to assume the role by adding the Amazon Resource Name (ARN) of the role to an Allow element for the sts:AssumeRole action.
• Giving AWS Access to a third party user - Use roles to delegate access to them. The third party can get access by assuming the role.
• IAM Database authentication
• AWS account owner (root user) alone has access to billing module in an individual account not created part of AWS Organization. Account owner has to activate IAM access and attach policies to provide billing access.
• If the account was created part of AWS Organization the feature is enabled by default.
• Then a BillingFullAccess policy is attached to user groups. With that all members of the user group gets access. Attaching to User groups is recommended approach over attach policy to user or role.
• To deny users access to Billing module set Deny for the action - aws-portal:*
• Managed Policies -  are standalone identity-based policies that you can attach to multiple users, groups, and roles in your AWS account. An AWS managed policy is a standalone policy that's created and administered by AWS.
• Inline Policy - is embedded part of the IAM Identity and defines the permissions which the principal can perform upon assuming the role. AWS suggested approach is to use managed policies.
• Identity based policy - are attached to user, group or role. They specify what that Identity can do using the policy. They can be inline or managed.
• Resource based policy - Are linked to resources like S3,  SQS, VPC and KMS.  They can be only inline. The policy specifies who has access to the resource and what actions can they perform. Also referred as Trust based relation.
• Service linked roles - Service-linked roles are predefined by the service and include all the permissions that the service requires to call other AWS services on your behalf. For example we can specify an IAM role that allows AWS CloudFormation to create, update, or delete your stack resources. 
• Temporary Credentials - Are short term credentials generated using STS
• Permission boundaries - Defines the max permissions an entity can have. 
• Allow you to delegate permission to create users and roles while preventing privilege escalation or unnecessarily broad permissions.
• Permission boundaries control the maximum permissions of a user or role created by a delegated admin. Users and roles created by delegated admins must have a permissions boundary
• "Effect": "Allow", 
• "Action": ["iam:CreateRole"], 
• "Resource": ["arn:aws:iam::ACCOUNT_ID:role/path/*"], "Condition": {"StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT_ID:policy/permissionboundary" } }

https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_AWS_identity_Permission_boundaries_&_delegation_SEC402-R1.pdf

Sharing access to users in other accounts -  Cross account access

• The account where the resource exists is the trusting account.
• The account where the principal exists is the trusted account.
• For cross account access - attach RBP to resource which need to be shared and IBP to the Principal. The RBP should mention the principal who will be trusted. The trust entity can be entire account, IAM users, IAM roles or assumed-role sessions. Likewise the IBP must allow access to the resource in trusting account. Only when both the policies 'Allow' the access will be enabled.
• Let's say we have Development and Production account. We want to enable DevOps admin group in Development account to access resources in Production account.
• Create a role in production account with Dev account ID marked as Trusted principal.
• In the development account limit the user groups which cannot assume the role by attaching permissions - Action: sts:AssumeRole and Effect as Deny. The ones which can access should be give Allow effect.
• Attribute based access control (ABAC) - is an authorization strategy based on tags which are attached to IAM and AWS resources. 
• Session tags - can be passed when a role is assumed. Policies can be configured to use tags to grant permissions to principals.
• SAML Attributes can also be for fine grained control within IAM. The SAML attributes can be passed as Session tags. 
• Using SAML IdP external user identities can be given permission to access AWS resources. The SAML authenticated users will assume a role which has 2 polices - (1) an IAM permission policy that specifies the resources the federated user is allowed to access and the actions they can have on the resources. (2) a role trust policy which specified who can assume the role.

{

    "Version": "2012-10-17",

    "Statement": {

      "Effect": "Allow",

      "Action": "sts:AssumeRoleWithSAML",

      "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/PROVIDER-NAME"},

      "Condition": {"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}}

    }

  }

• Allowing bucket access to another account using S3 Bucket policy - Account B - 111122223333 is allowed to access S3 bucket in account A.

{

  "Version": "2012-10-17",

  "Statement": {

    "Sid": "AccountBAccess1",

    "Effect": "Allow",

    "Principal": {"AWS": "111122223333"},

    "Action": "s3:*",

    "Resource": [

      "arn:aws:s3:::mybucket",

      "arn:aws:s3:::mybucket/*"

    ]

  }

}

Organization and Account Setup

• Organization can be created in 2 ways
• With all features (default)
• consolidated billing feature
• SCP cannot be applied for Org created by consolidated billing feature.
• SCP - are Org wide and applied at account level - basically they limit permissions for every request made by principal within the account. Meant only for member accounts. 
• AWS accounts can be organized in AWS Organizations into Organization Units (OUs), which can have child OUs and member accounts. These OUs can have different SCPs applied to them and the accounts can be moved between OUs. This means you can create heavily restrictive SCPs for a production AWS account, and less restrictive (or different) SCPs for a sandbox account. 
• SCPs cannot restrict the Master or management account of the Organization. This is a primary reason why it is best practice not to use the Organization Master account for anything other than Organization activities.
• SCPs also cannot restrict principals outside of the Organization. 
• SCP dont apply to resource based policies.
• SCP should be applied at OU level over account level as it simplifies policy management.
• The member accounts of an AWS Organization are unable to see the SCPs that have been applied to them.
• The default SCP is FullAWSAccess which grants Allow of * on *. The only time your SCPs should include an Allow statement is either in that policy or by using a custom policy that lists allowed services. 
• The AWS Control Tower service recommends an SCP for denying the root user.
• RegionEnforcement can be done with SCP -  "Sid": "RestrictRegion",  "Effect": "Deny"
• Restricting VPC internet accessibility can be done by SCP.
• GuardDuty is a great service from AWS for detecting compromises and more. SCP policy ensures it isn’t turned off, or that findings are filtered.
• https://summitroute.com/blog/2020/03/25/aws_scp_best_practices/

Enabling SAML Federated Access

• Client gets authenticated by the LDAP identity store through the ID Provider. IdP returns a SAML assertion to the client.
• Client uses that to Sign into SSO URL (endpoint) which connects to STS for temporary credentials. 
• Endpoint returns a signin URL as redirect which client can use to login to console.

Multi-account scenarios

• The management actions should be performed on the master account.
• Create seperate OU for infrastructure and security which can be managed central team which are responsible for infrastructure and security.
• Create a seperate OU for workloads - One for Prod Workloads and other OU for Non-Prod. The various business units can have their respective non-prod and prod accounts under the respective OUs.
• Use central IT account for
• hosting directory repository
• providing centralized DNS 
• federating user access
• managing EBS snapshots
• config management
• central logging
• centrally managed shared AMI
• patch management
• https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/
• Creating role in Shared services account Vs all accounts

AWS Landing Tower

• Helps automate multi-account setup through blueprints which are readily available for IAM, user federation,  centralized logging, setting cross account security audits. workflows for account provisioning and network configuration using account factory.
• Guardrails helps enforce policy using SCP or detect policy violation using AWS Config. These are pre-packaged governance rules which can be enabled within OU. They can be preventive or detective.
• Dashboard to view policy level summary across accounts. 

Cloudtrail for an Organization

• When setup at Org level is referred as Org trail - when done so, a trail with same name gets created in every member account. However member account cannot turn off logging to this trail.
• The logs stored in S3 follows the structure as folder with OrgID/Sub folders with AccountIDs/events
• Event history can be viewed for 90 days from the respective management account or member accounts.

Systems manager Automation

• Systems manager automation can be used to centrally manage AWS resources across multiple accounts.
• From the management account/region, we can execute automation tasks targetting accounts in other regions. The management account should assume an IAM role and the target accounts should delegate trust to the management account.
• To target a goup of accounts we could create a resource group which will help roll out the automation tasks across the resources in the group at once.
• Create an automation document (SSM document) in the management account and select the target accounts, regions and resource groups and the actions to be performed and when they will be performed.
• To save costs, we can stop EC2 instances across accounts by centrally executing automation document - StopEC2Instance. Likewise a group of such instances can also be started centrally. 

Providing access to Specific S3 Buckets to users 

Amazon S3 stores data in a flat structure; you create a bucket, and the bucket stores objects. Amazon S3 doesn’t have a hierarchy of sub-buckets or folders; however, tools like the AWS Management Console can emulate a folder hierarchy to present folders in a bucket by using the names of objects (also known as keys). 

https://aws.amazon.com/blogs/security/writing-iam-policies-grant-access-to-user-specific-folders-in-an-amazon-s3-bucket/#:~:text=The%20ListAllMyBuckets%20action%20grants%20David,all%20buckets%20for%20console%20access).

• Before I begin identifying the specific folders David can have access to, I have to give him two permissions that are required for Amazon S3 console access: ListAllMyBuckets and GetBucketLocation.
• The ListAllMyBuckets action grants David permission to list all the buckets in the AWS account, which is required for navigating to buckets in the Amazon S3 console (and as an aside, you currently can’t selectively filter out certain buckets, so users must have permission to list all buckets for console access). The console also does a GetBucketLocation call when users initially navigate to the Amazon S3 console.
• Although David should have access to only his home folder, he requires additional permissions so that he can navigate to his folder in the Amazon S3 console. David needs permission to list objects at the root level of the my-company bucket and in the home/ folder.
• Without the ListBucket permission, David can’t navigate to his folder because he won’t have permissions to view the contents of the root and home folders. When David tries to use the console to view the contents of the my-company bucket, the console will return an access denied error. 

• In addition to the root and home folders, David requires access to all objects in the home/David/ folder and any subfolders that he might create. Here’s a policy that allows this:

      {
        "Sid": "AllowListingOfUserFolder",
        "Action": ["s3:ListBucket"],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::my-company"],
        "Condition":{"StringLike":{"s3:prefix":["home/David/*"]}}
      }

• Finally, I specify David’s actions (such as read, write, and delete permissions) and limit them to just his home folder, as shown in the following policy:
      {
        "Sid": "AllowAllS3ActionsInUserFolder",
        "Effect": "Allow",
        "Action": ["s3:*"],
        "Resource": ["arn:aws:s3:::my-company/home/David/*"]
      }
  For the Action element, I specified s3:*, which means David has permission to do all Amazon S3 actions. 

S3 IAM Access Evaluation Sequence

https://aws.amazon.com/premiumsupport/knowledge-center/s3-troubleshoot-403/

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow