AWS Access Management

This document provides answers to common questions related to AWS access management.

How to provide cross-account access?

To provide cross-account access, you can use IAM roles.

1. Create an IAM Role in the Trusting Account: In the AWS account that owns the resources (the trusting account), create an IAM role.
2. Define Trust Relationship: In the role's trust relationship, specify the AWS account ID of the account that needs access (the trusted account). This allows users from the trusted account to assume the role.
3. Attach Permissions: Attach policies to the role that define what actions the trusted account can perform on the resources in the trusting account.
4. Grant Permission to Assume the Role: In the trusted account, grant IAM users or roles permission to assume the role created in the trusting account. This is done by creating a policy that allows the sts:AssumeRole action on the ARN of the role in the trusting account.
5. Assume the Role: Users in the trusted account can then assume the role to get temporary credentials to access the resources in the trusting account.

How to provide private bucket access to a user?

To provide access to a private S3 bucket for a specific IAM user:

1. Create an IAM User: If you haven't already, create an IAM user for the person who needs access.
2. Create a Bucket Policy or User Policy:
   • Bucket Policy: Attach a bucket policy to the S3 bucket. In the policy, you can specify the IAM user's ARN as the Principal and define the allowed S3 actions (e.g., s3:GetObject).
   • User Policy: Attach an inline or managed policy to the IAM user. This policy should grant the necessary S3 permissions for the specific bucket.

Example Bucket Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUserToAccessBucket",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-ID:user/USERNAME"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-private-bucket",
        "arn:aws:s3:::your-private-bucket/*"
      ]
    }
  ]
}

How to provide private bucket access to another AWS account?

To grant another AWS account access to your private S3 bucket:

1. Create a Bucket Policy: Attach a bucket policy to your S3 bucket.
2. Specify the Account in the Principal: In the bucket policy, set the Principal to the ARN of the AWS account you want to grant access to.
3. Define Permissions: Specify the S3 actions the other account is allowed to perform.

Example Bucket Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DelegateAccessToAnotherAccount",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::OTHER-ACCOUNT-ID:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-private-bucket/*"
    }
  ]
}

In the other AWS account, the IAM users who need to access the bucket must have policies attached to them that allow the corresponding S3 actions on your bucket's resources.

How to provide private bucket access to a user who doesn't have an AWS account?

You can use S3 pre-signed URLs to grant temporary access to specific objects in your private bucket.

1. Generate a Pre-signed URL: You can generate a pre-signed URL using the AWS SDK, AWS CLI, or AWS Management Console.
2. Specify Expiration Time: When generating the URL, you specify an expiration time. After this time, the URL will no longer be valid.
3. Share the URL: Share the generated URL with the user. Anyone with the URL can access the object until it expires.

Example using AWS CLI:

aws s3 presign s3://your-private-bucket/your-object.jpg --expires-in 604800

This command generates a pre-signed URL that is valid for 7 days (604800 seconds).

What is STS and how does it work?

AWS Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for IAM users or for users that you authenticate (federated users).

How it works:

1. Request Temporary Credentials: An IAM user or an application calls the AssumeRole API action (or other similar STS API calls like GetFederationToken or GetSessionToken).
2. STS Authenticates and Authorizes: STS authenticates the identity of the user making the request and then returns a set of temporary security credentials.
3. Use Temporary Credentials: The user or application uses the temporary credentials to make calls to AWS services. These credentials consist of an access key ID, a secret access key, and a session token.
4. Credentials Expire: The temporary credentials are valid for a specified duration, after which they expire.

STS is central to enabling cross-account access and identity federation.

How to provide access to a user in a private instance?

To provide access to a user for a private EC2 instance (an instance in a private subnet with no direct internet access):

1. Bastion Host (Jump Box):

   • Set up a bastion host (a small EC2 instance) in a public subnet.
   • Harden the bastion host by restricting access to specific IP addresses (e.g., your office IP) via security groups.
   • Users first SSH into the bastion host.
   • From the bastion host, they can then SSH into the private EC2 instance using its private IP address.

2. AWS Systems Manager Session Manager:

   • This is a more secure and manageable approach that doesn't require a bastion host or opening SSH ports.
   • Install the SSM Agent on the private instance.
   • Ensure the instance has an IAM role with the AmazonSSMManagedInstanceCore policy attached.
   • Ensure the VPC has the necessary VPC endpoints for Systems Manager (ssm, ssmmessages, ec2messages).
   • Users with the appropriate IAM permissions can then start a session to the instance through the AWS Management Console, AWS CLI, or SDKs.

3. VPN or Direct Connect:

   • For corporate environments, you can establish a VPN connection or a Direct Connect link between your on-premises network and your VPC.
   • This allows users on your corporate network to access the private instance directly using its private IP address, as if it were on the local network.

How to grant programmatic access to an application?

For applications running on AWS (e.g., EC2 instances, Lambda functions, ECS tasks), the most secure and recommended way to grant programmatic access is by using IAM Roles.

1. Create an IAM Role: Create an IAM role specifically for the application.
2. Define Trust Policy: Configure the trust policy of the role to allow the AWS service (e.g., ec2.amazonaws.com, lambda.amazonaws.com) to assume the role.
3. Attach Permissions Policy: Attach an IAM policy to the role that grants only the necessary permissions for the application to perform its tasks (principle of least privilege).
4. Assign Role to Resource: Assign this IAM role to the EC2 instance, Lambda function, or ECS task. The application running on that resource will automatically inherit the temporary credentials associated with the role, eliminating the need to store long-lived access keys.

For applications running outside AWS (e.g., on-premises servers, developer workstations), you can use IAM Users with Access Keys. However, this approach requires careful management of access keys.

1. Create an IAM User: Create a dedicated IAM user for the application.
2. Generate Access Keys: Generate an access key ID and secret access key for this user.
3. Attach Permissions Policy: Attach an IAM policy to the user that grants only the necessary permissions.
4. Configure Application: Configure your application to use these access keys. Crucially, store these keys securely (e.g., environment variables, AWS Secrets Manager, or a secure credential store) and avoid hardcoding them in your code.

How to restrict access to resources based on IP address?

You can restrict access to AWS resources based on the source IP address using several mechanisms:

1. IAM Policies (Condition Key aws:SourceIp):

   • You can add a condition to an IAM policy that allows or denies access only if the request originates from a specified IP address or range.
   • This is effective for controlling access to AWS APIs and services.

   Example IAM Policy Snippet: json { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": "203.0.113.0/24" } } } This policy denies all actions unless the request comes from the 203.0.113.0/24 IP range.

2. Security Groups:

   • For EC2 instances, RDS databases, and other network-attached resources, Security Groups act as virtual firewalls.
   • You can configure inbound and outbound rules to allow traffic only from specific IP addresses or CIDR blocks.

3. Network Access Control Lists (NACLs):

   • NACLs operate at the subnet level and provide a stateless firewall.
   • You can define rules to allow or deny traffic based on IP addresses, ports, and protocols for entire subnets.

4. AWS WAF (Web Application Firewall):

   • For web applications fronted by services like CloudFront, Application Load Balancer (ALB), or API Gateway, WAF can be used to create IP-based access control rules.

How to audit access to AWS resources?

Auditing access is crucial for security and compliance. AWS provides several services for this:

1. AWS CloudTrail:

   • CloudTrail records API calls and related events made by users, roles, or AWS services in your AWS account.
   • These logs provide a history of actions taken, including who made the request, what services were accessed, when the action occurred, and from which IP address.
   • You can store CloudTrail logs in S3 for long-term retention and analysis.

2. Amazon CloudWatch Logs:

   • CloudTrail logs can be sent to CloudWatch Logs, allowing you to create alarms and dashboards based on specific access patterns or unauthorized attempts.

3. AWS Config:

   • AWS Config continuously monitors and records your AWS resource configurations and allows you to automate the evaluation of recorded configurations against desired baselines.
   • It can help identify resources that are not compliant with your access policies.

4. IAM Access Analyzer:

   • IAM Access Analyzer helps you identify the resources in your organization and accounts, such as S3 buckets or IAM roles, that are shared with an external entity.
   • It helps you review and refine public and cross-account access.

5. VPC Flow Logs:

   • VPC Flow Logs capture information about the IP traffic going to and from network interfaces in your VPC.
   • While not directly an "access audit" tool in the sense of API calls, they are invaluable for network-level access troubleshooting and security analysis.