-
Notifications
You must be signed in to change notification settings - Fork 271
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
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. /close |
@kubevirt-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
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.
The text was updated successfully, but these errors were encountered: