I am currently following the guide published here on how to connect okteto to S3 using an IAM Role. I’ve hooked up several service accounts to IAM roles in other projects, but this one seems to be failing. I’m getting a continual restart with no clear error message, and the troubleshooting docs suggest this is because it cannot connect to s3.
We cannot use IAM Users in our org, so IAM roles are our only option. Whilst the policy I have created is identical to the recomended one, it differs in one respect, which is I’ve included an extra statement to allow for the decryption using our KMS key. All our S3 buckets are required to have Server Side KMS encryption as per another organisation security policy. I suspect this is why okteto is unable to connect to it. The IAM policy should be correct and I’ve done similar with other apps, so I’d appreciate if someone could confirm that this is supported and help me to debug what might be going wrong with our setup.
The extra statement in the IAM policy looks like the following. The rest of it is identical to the recomended.
@cheer.b95 could you share the entire definition of your IAM Role?
Also, could you share the logs of the okteto-registry pods?
The above is my config, and I can confirm the service account has the correct annotation and the pod has the correct AWS env variables, namely the
the IAM Role’s policy is as follows. It’s overly permissive for testing:
as far as logs go, we see this on loop before the pod just disappears.
The only thing I can think is that okteto is not able to handle server side encryption, or its not reading the
AWS_WEB_IDENTITY_TOKEN_FILE environment variable.
Would it be possible to test your setup without server-side encryption (on a different bucket) just to discard that? We’ll also do some testing around this internally.
Sadly not. Server side encryption is automatically applied to all our s3 buckets. We cannot disable it.
@cheer.b95 IAM Roles are not supported yet by the docker registry, they had a regression there and there is an open PR to fix it. In the meantime, you might use IAM users, or use a single registry replica and file system storage for now.
Another security policy prevents us from creating IAM users. We have to use roles. Hopefully this can be fixed quickly.
We’ll look into alternative storage for now but We would obviously prefer s3 if possible.
Is it possible to have a link to the helm chart code? I’ve not been able to find it in Github.
I can confirm switching to ‘byo’ and away from s3 temporarily fixed the issue. We’d like to switch to s3 and IAM roles at some point when this issue is resolved.
The helm chart code is not available through GitHub. However, you can inspect all helm charts by using helm pull, Helm | Helm Pull