0

I am having issues deploying my docker images to aws ecr as part of a terraform deployment and I am trying to think through the best long term strategy.

At the moment I have a terraform remote backend in s3 and dynamodb on let's call it my master account. I then have dev/test etc environments in separate accounts. The terraform deployment is currently run off my local machine (mac) and uses the aws 'master' account and its credentials which in turn assumes a role in the target deployment account to create the resources as per:

provider "aws" { // tell terraform which SDK it needs to load
  alias  = "target"
  region = var.region
  assume_role {

  role_arn = "arn:aws:iam::${var.deployment_account}:role/${var.provider_env_deployment_role_name}"
  }
}

I am creating a number of ecs services with Fargate deployments. The container images are built in separate repos by GitHub Actions and saved as GitHub packages. These package names and versions are being deployed after the creation of the ecr and service (maybe that's not ideal thinking about it) and this is where the problems arise.

The process is to pull the image from GitHub Packages, retag it and upload to the ecr using multiple executions of a null_resource local-exec. Works fine stand alone but has problems as part of the terraform process. I think the reason is that the other resources use the above provider to get permissions but as null_resource does not accept a provider it cannot get the permissions this way. So I have been passing the aws creds values into the shell. Not convinced this is really secure but that's currently moot as it ain't working either. I get this error:

Error saving credentials: error storing credentials - err: exit status 1, out: `error storing credentials - err: exit status 1, out: `The specified item already exists in the keychain.``

Part of me thinks this is the wrong approach and that as I migrate to deploying via a Github action I can separate the infrastructure deployment via terraform from what is really the application deployment and just use GitHub secrets to reset the credentials values then run the script.

Alternatively, maybe the keychain thing just goes away and my process will work fine? Secure ??

That's fine for this scenario but it isn't really a generic approach for all my use cases.

I am shortly going to start deploying multiple aws lambda functions with docker containers. Haven't done it before but it looks like the process is going to be: create ecr, deploy container, deploy lambda function. This really implies that the container deployment should integral to the terraform deployment which loops back to my issue with the local-exec??

I found Actions to deploy to ECR which would imply splitting the deployments into multiple files but that seems inelegant and potentially brittle.

Maybe there is a simple solution, but given where I am trying to go with this, what is my best approach?

Chanonry
  • 423
  • 7
  • 19

3 Answers3

1

I know this isn't a complete answer, but you should be pulling your AWS creds from environment variables. I don't really understand if you need credentials for different accounts, but if you do then swap them during the progress of your action. See https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html . Terraform should pick these up and automatically use them for AWS access.

Kevin Buchs
  • 2,520
  • 4
  • 36
  • 55
  • I am working through this but I think that is the essence of the solution. Use Actions to avoid the 'keychain' issue, configure all the account credentials as GitHub Secrets and pass the target deployment account credentials to the repeated calls to local-exec. I have not proved definitively that it works but it seems promising. – Chanonry Mar 30 '21 at 07:39
1

Instead of those hard coded access key/secret access keys I'd suggest making use of Github/AWS's ability to assume role through temporary credentials with OIDC https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services

You'd likely only define one initial role that you'd authenticate into and from there assume into the other accounts you're deploying into.

These the assume role credentials are only good for an hour and do not have the operation overhead of having to rotate them.

Tony Fruzza
  • 21
  • 2
0

As suggested by Kevin Buchs answer...

My primary issue was related to deploying from a mac and the use of the keychain. As this was not on the critical path I went round it and set up a GitHub Action.

The Action loaded environmental variables from GitHub secrets for my 'master' aws account credentials.

AWS_ACCESS_KEY_ID: ${{ secrets.NK_AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.NK_AWS_SECRET_ACCESS_KEY }}

I also loaded the target accounts credentials into environmental variables in the same way BUT with the prefix TF_VAR.

TF_VAR_DEVELOP_AWS_ACCESS_KEY_ID: ${{ secrets.DEVELOP_AWS_ACCESS_KEY_ID }}
TF_VAR_DEVELOP_AWS_SECRET_ACCESS_KEY: ${{ secrets.DEVELOP_AWS_SECRET_ACCESS_KEY }}

I then declare terraform variables which will be automatically populated from the environment variables.

variable "DEVELOP_AWS_ACCESS_KEY_ID" {
  description = "access key for the dev account"
  type = string
}
variable "DEVELOP_AWS_SECRET_ACCESS_KEY" {
  description = "secret access key for the dev account"
  type = string
}

And when I run a shell script with a local exec:

resource "null_resource" "image-upload-to-importcsv-ecr" {

   provisioner "local-exec" {
      command = "./ecr-push.sh ${var.DEVELOP_AWS_ACCESS_KEY_ID} ${var.DEVELOP_AWS_SECRET_ACCESS_KEY} "
   }
}

Within the script I can then use these arguments to set the credentials eg

AWS_ACCESS=$1
AWS_SECRET=$1
.....
export AWS_ACCESS_KEY_ID=${AWS_ACCESS}
export AWS_SECRET_ACCESS_KEY=${AWS_SECRET}

and the script now has credentials to do whatever.

Chanonry
  • 423
  • 7
  • 19