Multiple issues with AWS ECR feeds

[trond]

We’re on version 2020.3.1.
I’m trying to set up a feed for our AWS Elastic Container Registry. Our octopus server is running in a different account than the ECR feed. Octopus server is running in Kubernetes, and has a assumed role using KIAM - this means that the Octopus server container is able to make requests against AWS without any explicit access key/secret since its getting its credentials in the form of Instance profile credentials. Since ECR is running in a different account, we have a Lambda that allows all aws in our org access to ECR.

So my questions:

• I need to be able to specify which ECR repo to use, Octopus shouldn’t assume that the ECR repo is in the same account as the IAM User/Role it is using
• I need to be able to configure ECR without an explicit access key/secret, since credentials can be retrieved from the instance profile instead (we try and avoid using hard-coded credentials as much as possible). It isn’t clearly stated if access key/secret are required or optional so I’m confused if this should work at all.

It would be good to have someone at Octopus Deploy comment on this.

[Bob_Walker]

Hi @trond,

To make sure I understand your question correctly, your setup is:

• Octopus Server running under the account AWS Account A
• ECR is attached to the account AWS Account B

And you’d like to specify an ECR feed in Octopus without having to supply a key/secret.

In looking at the source code, the access key/secret is required. We pull the authorization token based on the values provided.

        static AuthorizationData GetAuthorizationData(string accessKey, [CanBeNull] SensitiveString secretKey, string region)
        {
            var regionEndpoint = Amazon.RegionEndpoint.GetBySystemName(region);
            var credentials = new BasicAWSCredentials(accessKey, secretKey?.Value);
            var client = new AmazonECRClient(credentials, regionEndpoint);
            try
            {
                var token = client.GetAuthorizationTokenAsync(new GetAuthorizationTokenRequest()).Result;
                var authToken = token.AuthorizationData.FirstOrDefault();
                if (authToken == null)
                {
                    throw new Exception("No AuthToken found");
                }

                return authToken;
            }
            catch (Exception ex)
            {
                throw new AuthenticationException($"Unable to retrieve AWS Authorization token:\r\n\t{ex.Message}");
            }
        }

I can forward this to our product team to get their thoughts on this.

[trond]

Hi Bob, corret.

One of the great things about AWS, is that credentials resolving is very standardized, also across programming languages. This makes it easy to piece together different tools (such as kiam, which is a system for injecting instance credentials into kubernetes pods). It doesn’t matter if our containers are using the boto3 library (aws lib for python), or aws sdk for Go or Java - as long as the default credential resolution chain is left as intended, everything just… works.

That said, I totally realize that an app such as Octopus needs to allow users to be able to specify credentials using hard-coded access keys and secrets. I only ask that you understand that this should be thought of as a last-resort way of using aws. The recommended approach for a service or a computer (or container) to gain access to aws will always be some variation of instance credentials, since these are short-lived and thus much more secure.

so to conclude my rant: please make access key/secret optional instead of required when communicating with aws, and make sure instance credentials are supported.

[Bob_Walker]

This or something similar has been brought up a few times before. I’ll raise it with our product team to get their take on it.