Let's create a first IAM user for Mary in a new iam.tf file using the aws_iam_user resource:

resource "aws_iam_user" "mary" {
  name = "mary"
  path = "/team/"
}

The path is purely optional and informative, I'm simply suggesting structured paths. So we'll have /apps/ as well later.

We can now create an AWS Access Key for our user Mary, using the aws_iam_access_key resource with reference to our user:

resource "aws_iam_access_key" "mary" {
  user = "${aws_iam_user.mary.name}"
}

And finally, as we know, we want to attach to this user the AmazonS3FullAccess managed policy, let's use the dedicated resource:

resource "aws_iam_user_policy_attachment" "mary_s3full" {
  user = "${aws_iam_user.mary.name}"
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3FullAccess"
}

Let's write an output so we know both parts of the key in outputs.tf:

output "mary" {
  value = "ACCESS_KEY: ${aws_iam_access_key.mary.id}, SECRET: ${aws_iam_access_key.mary.secret}"
}

Also, terraform apply this to create the mary user:

[...]
Outputs:
mary = ACCESS_KEY: AKIAJPQB7HBK2KLAARRQ, SECRET: wB+Trao2R8qTJ36IEE64GNIGTqeWrpMwid69Etna

Now, terraform apply this, and confirm using an S3 browser that you can access S3! Here's an example of creating a simple S3 bucket with s3cmd:

$ s3cmd --access_key=<mary_access_key> --secret_key=<mary_secret_key> mb s3://iacbook-iam-bucket
Bucket 's3://iacbook-iam-bucket/' created

Is this account really limited to S3, as it pretends to be? Let's try to list EC2 hosts with Mary's account using the aws command line (provided you configured the aws tool accordingly):

$ aws --profile iacbook-mary ec2 describe-hosts
An error occurred (UnauthorizedOperation) when calling the DescribeHosts operation: You are not authorized to perform this operation.

So it all looks good and secure! Mary can do her job on S3 safely.

Is there a similar managed policy for Joe, with a read-only scope on EC2? Fortunately, there is! It's creatively named AmazonEC2ReadOnlyAccess.

Let's create our second user, with this IAM policy in the iam.tf file:

resource "aws_iam_user" "joe" {
  name = "joe"
  path = "/team/"
}

resource "aws_iam_access_key" "joe" {
  user = "${aws_iam_user.joe.name}"
}

resource "aws_iam_user_policy_attachment" "joe_ec2ro" {
  user = "${aws_iam_user.joe.name}"
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess"
}

Don't forget the useful output that comes with it:

output "joe" {
  value = "ACCESS_KEY: ${aws_iam_access_key.joe.id}, SECRET: ${aws_iam_access_key.joe.secret}"
}

Next, terraform apply this once again, and can the Joe user see what's on S3? No, he can't:

$ s3cmd --access_key=<joe_access_key> --secret_key=<joe_secret_key> ls
ERROR: S3 error: 403 (AccessDenied): Access Denied

But can the Joe user simply list the EC2 VMs as he needs to, with the same command that was forbidden to Mary? Yes, he can:

$ aws --profile iacbook-joe ec2 describe-hosts
{
  "Hosts": []
}

We're on track to securely manage our infrastructure access using code!

We've used the CloudWatch Logs service in a previous recipe. If you remember, you had to enter once again your keys in the Docker Engine configuration. If you had 100 servers, your master keys would be on each of them. This is rather unnecessary, if you consider that the scope of this configuration in Docker is just to send logs. Fortunately, there's a managed IAM policy for that named CloudWatchLogsFullAccess.

So let's create another user, exactly as before for Mary and Joe, except this one will be for our Docker Engines and not for a real user in iam.tf. I suggest using a different path, just to separate real users and application users. However, that's totally optional and opinionated:

resource "aws_iam_user" "logs" {
  name = "logs"
  path = "/apps/"
}

resource "aws_iam_access_key" "logs" {
  user = "${aws_iam_user.logs.name}"
}

resource "aws_iam_user_policy_attachment" "logs_cloudwatch_full" {
  user = "${aws_iam_user.logs.name}"
  policy_arn = "arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
}

The relevant output in outputs.tf is as follows:

output "logs" {
  value = "ACCESS_KEY: ${aws_iam_access_key.logs.id}, SECRET: ${aws_iam_access_key.logs.secret}"
}

Now, terraform apply this and try the Enabling CloudWatch Logs for Docker with Terraform recipe again with those credentials instead of the master keys: it will still work on the CloudWatch scope, but if something goes wrong, it will never put the rest of your infrastructure in danger. The worst that can happen in this area is the total waste of the logs.

[...]
Outputs:

joe = ACCESS_KEY: AKIAJQPSXBKSD3DY47BQ, SECRET: VQgtQ7D8I+mxRX28/x5qbFk6cdyxZajhhSsh7Rha
logs = ACCESS_KEY: AKIAISIUXTG5RIJZAEYA, SECRET: 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
mary = ACCESS_KEY: AKIAJPQB7HBK2KLAARRQ, SECRET: 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