AWS ABC

The goal of this tutorial page is trying to make a user-friendly introduction to AWS

AWS account root users and IAM users

AWS has two types of users, account root user and IAM user.  You are either the account owner (root user) or you are an AWS Identity and Access Management (IAM) user. The root user is created when the AWS account is created. IAM users are created by the root user or an IAM administrator for the account. All AWS users have security credentials. 

Root user credentials

The credentials of the account owner allow full access to all resources in the account. You can't use IAM policies to explicitly deny the root user access to resources. You can only use an AWS Organizations service control policy (SCP) to limit the permissions of the root user of a member account. Because of this, we recommend that you create an IAM user with administrator permissions to use for everyday AWS tasks and lock away the access keys for the root user.

There are specific tasks that can be performed only by the root user. For example, only the root user can close your account. If you need to perform a task that requires the root user, sign in to the AWS Management Console using the email address and password of the root user. For more information, see Tasks that require root user credentials.

IAM credentials

With IAM, you can securely control access to AWS services and resources for users in your AWS account. For example, if you require administrator-level permissions, you can create an IAM user, grant that user full access to your account, and then use those credentials to interact with AWS. If you need to modify or revoke your permissions, you can delete or modify the policies that are associated with that IAM user.

If you have multiple users that require access to your AWS account, create unique credentials for each user and define who has access to which resources. You don't need to and shouldn't share credentials. For example, you can create IAM users with read-only access to resources in your AWS account and distribute the credentials for each IAM user to one of your users.

The above are from this link (with minor rewording): https://docs.aws.amazon.com/accounts/latest/reference/root-user-vs-iam.html

AWS ARN

Amazon Resource Names (ARNs) uniquely identify AWS resources. We require an ARN when you need to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls.

ARN follow the following naming conventions

arn:partition:service:region:account-id:resource-id

arn:partition:service:region:account-id:resource-type/resource-id

arn:partition:service:region:account-id:resource-type:resource-id

ARNs are delimited by colons, and composed of segments, which are the parts separated by colons (:). The specific components and values used in the segments of an ARN depend on which AWS service the ARN is for. Sometimes, some segments in ARN is omitted and therefore you can see something like:

arn:partition:::resource-type/resource-id

See here for more details: https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html

Connecting S3 - EC2

There are three things one needs to note about connecting S3-EC2. 

1. Create an IAM that allows EC2 to access S3

2. Create an S3 bucket and set the permission that allows the EC2. You may also want to add encryption when you create the S3 bucket. You can either use the default key associated with your account or create a key. Also in the permission/policy, you need to add the arn of the ec2 instance and specify s3 bucket in the resource.

3. In the IAM, add permission to access s3, and use kms

Port forwarding  using IPTABLES

nginx reverse proxy seems not working. It turns out that using iptables to map the port 80 to 8501 works well.  That is, do the following command on the instance that you started streamlit. 

sudo iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-ports 8501

Request SSL certificate

1. You need to generate .csr file and .key file on any linux server by the following command

openssl req -nodes -newkey rsa:2048 -sha256 -keyout YOUR_SERVER_NAME.key -out YOUR_SERVER_NAME.csr -subj "/C=US/ST=New Jersey/L=Princeton/O=Your Organization/OU=Division of Your Organization/CN=YOUR_SERVER_NAME"

2. This will generate a .csr file and a .key file. You can use the .csr file to apply for the SSL certificate and the .key file should be uploaded to your server that the SSL certificate will take effect. In other words, the .key file will need to match with the SSL certificate to indicate you are the certificate holder.  Note that the YOUR_SERVER_NAME must be a URL that can be reached from internet, for example, it could be a loadbalancer URL, or the IP/DNS towards a server. 

AWSCLI

1. install awscli by: pip install awscli

2. Setup awscli. 

First, go to ~/.aws/ and edit the credentials file. In the credentials file, you need to enter

[default]

aws_access_key_id=YOUR_ID

aws_secret_access_key=YOUR KEY

aws_session_token=YOUR TOKEN

3. Now you are ready to go. To list all your s3 buckets, in command line, type

aws s3 ls

To list details of a s3 bucket, type:

aws s3 ls s3://your-bucket-name

To copy files from local to s3

aws s3 cp my-local-file s3://your-bucket-name

To copy files between s3 buckets

aws s3 cp s3://bucket1/files s3://buckt2/

To copy files from s3 to local

aws s3 cp s3://bucket/files .

Note: sync is recommended over cp.

More commands, please see this link: https://www.bluematador.com/learn/aws-cli-cheatsheet

JSON Policy File

Access and permission in AWS is defined by the JSON policy file. The file is made of one or more statement segments. 

• Version – Specify the version of the policy language that you want to use. As a best practice, use the latest 2012-10-17 version.

• Statement – Use this main policy element as a container for the following elements. You can include more than one statement in a policy. Each statement has the following elements (some are optional)

  • Sid (Optional) – Include an optional statement ID to differentiate between your statements.

  • Effect – Use Allow or Deny to indicate whether the policy allows or denies access.

  • Principal (Required in only some circumstances) – If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.

  • Action – Include a list of actions that the policy allows or denies.

  • Resource (Required in only some circumstances) – If you create an IAM permissions policy, you must specify a list of resources to which the actions apply. If you create a resource-based policy, this element is optional. If you do not include this element, then the resource to which the action applies is the resource to which the policy is attached.

  • Condition (Optional) – Specify the circumstances under which the policy grants permission.

Example JSON policy file is as follows

{

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

  "Statement": [{

    "Sid": "1",

    "Effect": "Allow",

    "Principal": {"AWS": ["arn:aws:iam::account-id:root"]},

    "Action": "s3:*",

    "Resource": [

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

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

    ]

  }]

}

For more details, see here: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html