-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Improve user experience for creating / updating secrets #4822
Comments
@liggitt I know you have some opinions on this matter |
https://github.com/GoogleCloudPlatform/kubernetes/pull/4591/files#diff-24507fbfb739669903cc0ecbeb8769a5R77 is an example of what has to be done currently to create a secret |
I imagine a kubectl command that supports these use cases:
|
@liggitt And presumably a switch to say whether a particular thing should be base64 encoded, yes? |
@pmorie I thought secrets always had to be base-64 encoded |
@liggitt they do but some users may have pre-encoded artifacts they want to On Wed, Feb 25, 2015 at 2:42 PM, Jordan Liggitt notifications@github.com
|
This is config generation, similar to kubectl run-container and kubectl expose. The same pattern would work for this. |
@sallyom is prototyping an openshift experimental command to let you bundle a secret from a directory, based on experience with that, we may look to push it upstream to Kubernetes for feedback |
I wanted this last week. Looking forward to it. |
This would be great. Per #7311 , it should be possible to invoke this via library call also, not just kubectl command. |
+1...this is so necessary! |
If I push a secret command for kubectl is that subject to the v1 freeze? See: https://github.com/openshift/origin/blob/master/pkg/cmd/experimental/bundlesecret/bundle_secret.go |
It becomes A triage issue - do we think the UX is bad enough that this is On Sun, May 31, 2015 at 12:14 PM, Derek Carr notifications@github.com
|
I'll flag this a a 1.0 candidate, but I don't think it will fly. |
I just don't want to push something if it's not going to make it since there are other things I can look at pre-1.0. Right now, there is NO end user experience to ease creation of secrets so was not sure if this fell under a general user experience bucket. In practice, it is a pain to base64 and build JSON/Yaml. Let me know, referenced command is not too big, but I can imagine nits on naming. Right now, it's an experimental openshift command. Sent from my iPhone
|
I shoulda done something for this already :-/
|
The code-complete deadline for 1.0 is basically Friday, so I'd prefer to defer this until after the big 1.0 push if possible. |
Previous attempt to do something in this space was #7975. |
More generally, I'd be happy to have support for "experimental" commands in kubectl. I'll take a look at bundle-secret. |
+1 to stash 🏆 |
I still like "new" as the creation (but that opens the door for much more Maybe I'm just wrong and "create" is the in-wall plumbing, "new" is exposed On Fri, Oct 16, 2015 at 11:01 AM, Paul Morie notifications@github.com
|
What about "deposit"? as in to a vault. Or "escrow"? Nah. "confide" or On Fri, Oct 16, 2015 at 11:08 AM, Tim Hockin thockin@google.com wrote:
|
I'm afraid the trophy has already been awarded @thockin |
hrm |
I like deposit pretty well, actually. |
vault uses read/write - https://vaultproject.io/docs/commands/read-write.html |
wait no, i like bury. |
I just had the same thought re bury, ha... |
|
@bgrant0607 +1 to picking a name and moving on. |
jolly good |
*secrets away to write a CLI command... |
@derekwaynecarr now that we've settled on the name, would it be worth circling back here with an updated set of usage examples? |
@ncdc - will comment with an updated set of usage patterns. |
This is what a first PR would look like:
It appears to meet the semantics @bgrant0607 expressed here: It appears to satisfy the desires of @thockin as understood here: It uses OpenShift has additional subcommands for basicauth and sshauth secrets, but don't think that should block getting the initial syntax. If we upstream that it can follow-on. Similarly, OpenShift has Open for debate if you want:
Please ack if you are good on |
If you do |
@ncdc - yes, need to check if we do that in oc On Friday, October 16, 2015, Andy Goldstein notifications@github.com
|
-1 on the cute proposals - our job is not to reach for a thesaurus, it's to The reason why the "command noun verb " shows up in a lot of places Interactions with secrets are rarely one touch. The three most likely are I'm not in love with the "concept command" as a top level... but generic On Fri, Oct 16, 2015 at 2:20 PM, Prashanth B notifications@github.com
|
@smarterclayton - can you comment on the result I proposed "kubectl secret" On Friday, October 16, 2015, Clayton Coleman <notifications@github.com
|
Yes I'm ok with the current syntax at a high level. |
This also includes a script to generate secrets configuration to support these examples until kubernetes#4822 is resolved.
The serialized form of secret data is a base64 encoded string. Currently this means that in order to create a secret, a user has to craft a json or yaml field containing their encoded secret data. There should be a way for a user to create a secret from a set of cleartext files, binary files, or cleartext values specified from the command line.
The text was updated successfully, but these errors were encountered: