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

CDI importer requires static credentials for S3 and GCS (renewed) #3429

Open
russellcain opened this issue Sep 9, 2024 · 0 comments · May be fixed by #3433
Open

CDI importer requires static credentials for S3 and GCS (renewed) #3429

russellcain opened this issue Sep 9, 2024 · 0 comments · May be fixed by #3433

Comments

@russellcain
Copy link

This is a reopening of #3026 -- It was marked stale, but will be worked on this week.

Is your feature request related to a problem? Please describe:
Workloads should not have access to long-lived credentials. In cloud environments in particular, there are mechanisms for distributing short-lived credentials and SDKs support fetching and utilizing such creds. CDI prevents using the security best practice of using short-lived credentials for image retrieval from S3 and GCS sources.

Describe the solution you'd like:
CDI's operator should provide a method for specifying the image importer pod's ServiceAccount. This would enable access to existing credential distribution mechanisms: AWS's IRSA credentials as well as GKE Workload Identity. Additionally, the importer will need to be updated to rely on "ambient" credentials (retrieved by the cloud provider SDK), instead of the importer's current hard-coded reliance on static credentials. This could be accomplished by extending the S3DataSource and GCSDataSource structs with a serviceAccountName member, updating the relevant function signatures, and then branching when creating the client.

Describe alternatives you've considered:
Currently have created a specific IAM user, issued an access key ID and secret key, and using a set of hard-coded creds in a Kubernetes secret referenced by the importer. It "works", at the cost of violating existing security approaches for workload authentication.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant