Add kubectl create secret --from-base64-literal and --random-value-for-key

[ash2k]

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:

• Secret data hitting the disk is undesirable as it's potentially less secure.
• Secret is potentially exposed on disk, even if briefly.
• It's a hassle to clean up the file in the script, potentially leaving it behind, exposing it later.

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 the key 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.

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

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.

[xuzhenglun]

/assign

maybe it is festiable by using stdin device, here is my workaround.

head -c 64 /dev/urandom | kubectl create secret genetic my-secret --from-file=/dev/stdin

EDIT:
Although there is a workaround, I still vote to adding this flag.

1. This method seems not portiable in Windows(Sorry I'm not familiar with Windows, correct me if I'm wrong).
2. Flag way is simpler and have better experience.

[xuzhenglun]

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.

[ash2k]

Do you want to implement this @ash2k ?

Not anytime soon. I need the feature but don't have capacity to build it right now.

[ak20102763]

Hi @ash2k / @xuzhenglun , if this feature is accepted, kubectl create secret generic --random-value-for-key=key=64 this could be one way to add it. Developed and tested this, let me know if I can contribute.

[Bhargav-manepalli]

Hi @xuzhenglun / @ash2k,

I have worked on this feature: kubectl create secret generic --random-value-for-key=key=64.
I am ready to contribute my implementation via a pull request.

[xuzhenglun]

@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 --random-value-for-key could lack of versatility:

1. Is the randomness cryptographically random or just ordinary pseudo-random. If people want to decide how to generate the data, maybe --from-base64-literal is better.
2. This semantics is not explicitly shown in the flag name, so 64 seems not very clear about the length of random bytes.

[ardaguclu]

/transfer kubectl

[ak20102763]

@xuzhenglun I understand your concern, I am using crypto/rand package that generates high entropy cryptographic randomness, which can be suitable to generate keys, tokens. And if user needs just high entropy random bytes irrespective of how it is created, generating it through secret creation and storing it would give better experience. Though as you said, user may want to decide how to generate data, then --from-base64-literal would be a better option.

And here is more information about this flag:
--random-value-for-key=key=size
Specify a key and size to generate random binary value from crypto/rand package (e.g., --random-value-for-key=key=64). The size should be a positive integer representing the number of bytes.

[Bhargav-manepalli]

@xuzhenglun , I've implemented the --from-base64-literal=<base64 encoded key> flag in kubectl. With this flag, when creating a secret, the secret will be created with the encoded value. The logic is handled in kubectl, where the base64-encoded string from the CLI arguments is decoded and passed as the decoded key to the API server. The API server will then create an encoded secret for us. This ensures flexibility for users while maintaining proper handling of encoded secrets.