Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-enable support for IAM Roles for Service Accounts #211

Closed
hasheddan opened this issue May 5, 2020 · 3 comments · Fixed by crossplane/crossplane#1577 or #242
Closed

Re-enable support for IAM Roles for Service Accounts #211

hasheddan opened this issue May 5, 2020 · 3 comments · Fixed by crossplane/crossplane#1577 or #242
Assignees
Labels
bug Something isn't working

Comments

@hasheddan
Copy link
Member

What happened?

To conform with Crossplane's new default security context for stacks (crossplane/crossplane#1444), the provider-aws container now runs as non-root (#202). Because we set the non-root user in the Dockerfile, users must rebuild the container to run as root user in order to be able to read the AWS credentials that are injected from the service account into /var/run/secrets/ in the container.

How can we fix it?

There are a few immediate options I could see here:

  1. Create a separate release for running in "insecure mode". This could use a workaround like Fix AWS IAM Roles for Service Accounts permission problem. kubernetes-sigs/external-dns#1185 (comment).
  2. Add fields on ClusterStackInstall (or the next iteration of the installation unit). This seems like the most sustainable long-term solution as there is desire to move away from including an install.yaml in provider packages (install.yaml allows a full Deployment spec to be declared which can be problematic crossplane/crossplane#1441).
  3. Document how a user may build their own package from source in AUTHENTICATION.md. This is a good short-term solution.
@hasheddan hasheddan added the bug Something isn't working label May 5, 2020
@hasheddan hasheddan self-assigned this May 5, 2020
@muvaf
Copy link
Member

muvaf commented May 16, 2020

@hasheddan Looking at kubernetes-sigs/external-dns#1185 (comment) , is there any unexpected or bad side effects of using securityContext.fsGroup: 65534 for all packages in package-manager?

@hasheddan
Copy link
Member Author

@muvaf I think that would be fine. Another option would be to just set it in the install.yaml for AWS and then run Crossplane with —insecure-pass-full-deployment, which would cause Crossplane to not overwrite the security context. That being said, it would be nice if this “just worked”, so I think setting it in Crossplane should be the right solution 👍 I’ll get this fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants