-
Notifications
You must be signed in to change notification settings - Fork 909
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
Add kubectl create secret --from-base64-literal #1654
Comments
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The 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. |
/assign maybe it is festiable by using stdin device, here is my workaround.
EDIT:
|
WDYT about thie feature? @eddiezane Do you want to implement this @ash2k ? If I may, once this feature is accepted, I'm happy to raise a PR to make it happen. |
Not anytime soon. I need the feature but don't have capacity to build it right now. |
Hi @ash2k / @xuzhenglun , if this feature is accepted, |
Hi @xuzhenglun / @ash2k, I have worked on this feature: |
@Bhargav-manepalli / @ak20102763 Don't worry, I'm fine if you want to take over it. But I'm not sure that such change will be accepted, You would be better to ensure this with approver of sig-cli. IMHO, flag likes
|
/transfer kubectl |
@xuzhenglun I understand your concern, I am using And here is more information about this flag: |
@xuzhenglun , I've implemented the |
That’s really awesome, thanks for your contribution. Feel free to raise a PR and link with this issue when you are ready. @Bhargav-manepalli /assign @Bhargav-manepalli |
Great work @Bhargav-manepalli, I have the same implementation for this other flag. Please raise a PR. |
Thanks @ak20102763 , @xuzhenglun |
I think this should be triaged by sig-cli first to move forward. Because adding new flag requires strong justification. |
What would you like to be added?
kubectl create secret --from-literal=key=secret-value
is very handy. I have a use case where I'm creating a secret that needs to be binary (an encryption key), be of a certain size, and use all of those bits for entropy. I'm taking randomness from/dev/urandom
but cannot use it as a literal value since it's binary.I could put the secret material into a file and use
kubectl create secret --from-file=./file
but:Ideally I'd use something like
kubectl create secret --from-base64-literal="key=$(head -c 64 /dev/urandom | base64)"
to generate a value of 64 bytes, base64 encode it, pass to kubectl. It would decode it, persist into the cluster.Yet another idea (can open a separate issue) is to have
--random-value-for-key=key=64
. It would generate a random value of length 64 and persist it into thekey
key. Even nicer and more secure (secret is not exposed on disk and via command line flags, where it can be seen by other processes) for bootstrapping a secret (from a script or console)./sig cli
Why is this needed?
Better scripting experience, more secure secret data handling.
The text was updated successfully, but these errors were encountered: