⛅ Cross-account AWS uploads

[major]

The AWS upload experience could be improved a bit by:

1. Researching how to set up cross-account trust in AWS IAM
2. Add code and documentation to explain minimal travis configuration #2.

IAM cross-account trust

For those trying to run osbuild-composer as a service to upload to multiple AWS accounts, it makes sense to use a single IAM user for osbuild-composer and then have other accounts trust that user to upload/import in their account.

For example, user bob could exist in account 1001 in AWS. The user alice (account 2002) wants bob to upload an image to her account and import it, but alice does not want to give bob credentials for an IAM user in her account.

In this case, alice should be able to create a role in her IAM account and allow bob to use his IAM user to perform certain operations in her account.

This will require some research to ensure it works properly.

[major]

Relevant AWS docs: https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-cli/

[major]

If we think about this as a service account that is uploading/importing into a customer account, the steps look something like this:

Customer account steps

In the customer account, go to S3 and make a bucket called cross-account-testing. Go to IAM and add a policy called cross-account-testing:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObjectAcl",
                "s3:GetObject",
                "s3:GetObjectTagging",
                "s3:ListBucket",
                "s3:PutObjectTagging",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::mhayden-cross-account-testing/*",
                "arn:aws:s3:::mhayden-cross-account-testing"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:HeadBucket",
            "Resource": "*"
        }
    ]
}

Now add a role called cross-account-testing with a trust relationship for the service account. This allows an IAM user in the service account to assume this role that we are creating:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_NUMBER_OF_SERVICE_ACCOUNT:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

Attach the cross-account-testing policy to that role so that the role allows access to the S3 bucket we created.

Service account steps

Create a policy called cross-account-policy that allows a new service user to list its available roles and assume a role provided in the customer account:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListRoles",
                "sts:AssumeRole"
            ],
            "Resource": "*"
        }
    ]
}

Create a user called cross-account-testing and attach the cross-account-policy to it.

Testing it out

As the service account IAM user, check the caller identity to make sure it's working:

$ aws --profile cross-account sts get-caller-identity
{
    "UserId": "xxx",
    "Account": "xxx",
    "Arn": "arn:aws:iam::ACCOUNT_NUMBER_OF_SERVICE_ACCOUNT:user/cross-account-testing"
}

Now list the available roles for the service account IAM user:

$ aws iam list-roles
-- SNIP --
{
    "Path": "/",
    "RoleName": "cross-account-testing",
    "RoleId": "xxx",
    "Arn": "arn:aws:iam::CUSTOMER_ACCOUNT_NUMBER:role/cross-account-testing",
    "CreateDate": "2020-07-14T14:47:36Z",
    "AssumeRolePolicyDocument": {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam::SERVICE_ACCOUNT_NUMBER:root"
                },
                "Action": "sts:AssumeRole",
                "Condition": {}
            }
        ]
    },
    "MaxSessionDuration": 3600
},

-- SNIP --

Use the ARN to assume the cross-account-testing role inside the customer's account.

$ aws --profile cross-account sts assume-role --role-arn "arn:aws:iam::CUSTOMER_ACCOUNT_NUMBER:role/cross-account-testing" --role-session-name AWSCLI-Session
{
    "Credentials": {
        "AccessKeyId": "xxx",
        "SecretAccessKey": "xxx",
        "SessionToken": "xxx",
        "Expiration": "2020-07-14T15:51:28Z"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "xxx:AWSCLI-Session",
        "Arn": "arn:aws:sts::CUSTOMER_ACCOUNT_NUMBER:assumed-role/cross-account-testing/AWSCLI-Session"
    }
}

Try to upload something to the customer S3 bucket using the service account's IAM user (that has assumed the role of the customer):

# touch test.txt
$ aws s3 cp test.txt s3://cross-account-testing
upload: test.txt to s3://cross-account-testing/test.txt
$ aws s3 ls cross-account-testing                      
2020-07-14 09:53:20      0 test.txt

[major]

It looks like osbuild-composer will need to know how to:

Use an AWS session token

It looks like we are using an empty string here (which means to ignore the session token), but the token is automatically provided when we assume the role in the other account (see second section for explanation):

func New(region, accessKeyID, accessKey string) (*AWS, error) {
	// Session credentials
	creds := credentials.NewStaticCredentials(accessKeyID, accessKey, "")

	// Create a Session with a custom region
	sess, err := session.NewSession(&aws.Config{
		Credentials: creds,
		Region:      aws.String(region),
	})
	if err != nil {
		return nil, err
	}

	return &AWS{
		uploader: s3manager.NewUploader(sess),
		importer: ec2.New(sess),
		s3:       s3.New(sess),
	}, nil
}

Assume a role and use those credentials.

This will require some more work to determine how we want to handle the inputs. If IAM is set up correctly, osbuild-composer would do something like this:

1. Get the ARN from the user. Example: arn:aws:iam::CUSTOMER_ACCOUNT_NUMBER:role/ROLE_IN_CUSTOMER_ACCOUNT"

2. Use that ARN to acquire temporary credentials for the assumed role. These are returned in JSON format:

{
    "Credentials": {
        "AccessKeyId": "xxx",
        "SecretAccessKey": "xxx",
        "SessionToken": "xxx",
        "Expiration": "2020-07-14T15:51:28Z"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "xxx:AWSCLI-Session",
        "Arn": "arn:aws:sts::CUSTOMER_ACCOUNT_NUMBER:assumed-role/cross-account-testing/AWSCLI-Session"
    }
}

3. Authenticate to AWS using the access key, secret access key, and the session token.

[github-actions]

This issue is stale because it had no activity for the past 365 days. Remove the "Stale" label or add a comment, otherwise this issue will be closed in 30 days.