1

I have an AWS CodePipeline with the build step using CodeBuild. I was previously using a managed image for this build job and I was able to use the follow command without issue:

aws ecr get-login --no-include-email --region us-east-1

Now I've switched over to a custom image to improve build time. The command failed and after some troubleshooting I realized the custom image didn't have AWS CLI installed. Now that AWS CLI is installed the above login line is exiting with error code 127. I believe this is because I followed all steps in this aws setup guide, except for aws configure.

I can configure but that's inconvenient because I need to take additional steps to obscure the secret and so on.

This question is not about those additional steps. I'm simply asking about the explanatory mechanism. It seems to me that the managed image would have environment variables available so login works, so why aren't those environment variables also allowing the custom image to login? I have the same build job, pipeline, and service role in both cases, just the different image.

I'd also note that CodeBuild and CodePipeline aren't currently used tags in ServerFault, so let me know if I should prefer a different StackExchange. ServerFault was recommended by this post on meta.

1 Answer 1

0

There is no difference. Custom CodeBuild containers don't need to use aws configure if all other build factors are appropriately configured.

The issue you describe is explained by ECR configuration, not a CodeBuild variance.

Run the following on a managed image:

  - echo $AWS_ACCESS_KEY_ID
  - echo $AWS_SECRET_ACCESS_KEY
  - echo $AWS_SESSION_TOKEN

  - cd /
  - ls
  - cd ~
  - ls
  - cd ~/.aws
  - ls

Notice that CodeBuild is locked down. It won't echo the environment variables needed, and it won't allow you to see the physical files either. This possibly indicates a difference in mechanism: You are trying to use environment variables, but the managed image is provisioned with physical files, so the managed image doesn't need to run aws configure.

This seems to indicate that you should provision the custom container with aws pre-configured as well, but this means you will commit to ECR or wherever else with plain text KEY_ID and ACCESS_KEY barring very elaborate workarounds. In addition, you cannot pre-configure AWS_SESSION_TOKEN as it will time out after some time. Again, you could configure some systems to give a fixed session an infinite timeout, but this is an antipattern because the session token time out is a security feature.

Instead of doing all that, check ECR permissions and your docker install:

1 - Go to ECR permissions and add a new permission statement. Previously you probably followed the official tutorial which grants ECR permissions to codebuild.amazonaws.com. In addition to that, because your build is within a pipeline, add codepipeline.amazonaws.com and any other IAM entities which are involved should be added to the IAM entities section of the permission.

2 - For docker, just check it has been installed. You mention that the custom image was missing aws cli and that you added that, but your custom image was also likely missing docker and I haven't seen you confirm that has been installed. As an example of what the error will look like, the line you mention throw something like the below if docker is not installed on Ubuntu:

/codebuild/output/tmp/script.sh: 4: /codebuild/output/tmp/script.sh: docker: not found

If docker is installed, also make sure it's running.

A final issue if you are working at an organization may be that there is a non-obvious AWS security policy in place blocking you. For example, enabling wildcard permissions is considered insecure, so one company I worked at automatically rolled back IAM users and policies which enabled wildcard access to any AWS service. Ironically, specifying specific ECR permissions on an IAM user worked while enabling all permissions failed in that case.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .