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.

/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.

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.

Do you want to implement this @ash2k ?

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, 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.

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.

@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.

/transfer kubectl

@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.

@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.

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
/unassign

Great work @Bhargav-manepalli, I have the same implementation for this other flag. Please raise a PR.

Thanks @ak20102763 , @xuzhenglun
I've submitted a pull request that implements the --from-base64-literal flag for kubectl create secret generic.
The implementation includes the new flag, associated logic, unit tests.
I'd appreciate your review and feedback.

I think this should be triaged by sig-cli first to move forward. Because adding new flag requires strong justification.