-
Notifications
You must be signed in to change notification settings - Fork 286
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
Allow placing synced secrets directly in the data
key
#1196
Comments
is any way to achieve what is described in request? |
Not that I've found in terms of a workaround but the fix in the code does look fairly straighforward at first glance... |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale
…On Jan 19, 2024 at 4:00 AM -0500, Kubernetes Triage Robot ***@***.***>, wrote:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed
You can:
• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Really? no interest in this? This is really surprising to me. Because re-mapping all secret keys ie. when taken from secretmanager or whatever store manually key by key is just insane :D |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Hi I have the same problem I'm using Azure KevVault, but I have to import as one secret per environment variable, also I have 10 services each one with 5-10 environment variables, so I end up with so many secrets in my Azure KeyVault. It is so difficult to maintain my envs this way, I think it would be a better idea to be able to import an May be I'm wrong and it's an easier way to import an This is my current SecretProvider class for one of my services: apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: $PROVIDER-NAME
spec:
provider: azure
parameters:
usePodIdentity: "false"
useVMManagedIdentity: "true"
keyvaultName: $KEYVAULT_NAME
userAssignedIdentityID: $IDENTITY_ID
tenantId: $TENANT_ID
objects: |
array:
- |
objectName: secret01
objectType: secret
- |
objectName: secret02
objectType: secret
- |
objectName: secret03
objectType: secret
- |
objectName: secret04
objectType: secret
- |
objectName: secret05
objectType: secret
- |
objectName: secret06
objectType: secret
- |
objectName: secret07
objectType: secret
- |
objectName: secret08
objectType: secret
- |
objectName: secret09
objectType: secret
- |
objectName: secret10
objectType: secret
- |
objectName: secret11
objectType: secret
- |
objectName: secret12
objectType: secret
- |
objectName: secret13
objectType: secret
- |
objectName: secret14
objectType: secret
secretObjects:
- data:
- objectName: secret01
key: ENVIRONMENT01
- objectName: secret02
key: ENVIRONMENT02
- objectName: secret03
key: ENVIRONMENT03
- objectName: secret04
key: ENVIRONMENT04
- objectName: secret05
key: ENVIRONMENT05
- objectName: secret06
key: ENVIRONMENT06
- objectName: secret07
key: ENVIRONMENT07
- objectName: secret08
key: ENVIRONMENT08
- objectName: secret09
key: ENVIRONMENT09
- objectName: secret10
key: ENVIRONMENT10
- objectName: secret11
key: ENVIRONMENT11
- objectName: secret12
key: ENVIRONMENT12
- objectName: secret13
key: ENVIRONMENT13
- objectName: secret14
key: ENVIRONMENT14
secretName: $SECRET_NAME
type: Opaque |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". 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. |
Describe the solution you'd like
First, to summarize The Problem
Right now the structure of a
secretObject
(docs|source) forces you (as far as I could tell, anyway) to load the contents of your secret into a subkey of the data key. This is an unfortunate limitation because the KubernetesenvFrom.secretRef
function does not support loading from a subKey.What I wanted to be able to do:
My AWS Secrets Manager secret:
My SecretProviderClass:
For posterity, the relevant parts of my Deployment:
Expectation:
Reality:
Environment:
kubectl version
): 1.23 (but AFAIK this limitation still exists on 1.26)The text was updated successfully, but these errors were encountered: