Skip to content
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

Closed
pmorie opened this issue Feb 25, 2015 · 98 comments
Closed

Improve user experience for creating / updating secrets #4822

pmorie opened this issue Feb 25, 2015 · 98 comments
Assignees
Labels
area/kubectl area/security area/usability kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.

Comments

@pmorie
Copy link
Member

pmorie commented Feb 25, 2015

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.

@pmorie
Copy link
Member Author

pmorie commented Feb 25, 2015

@liggitt I know you have some opinions on this matter

@liggitt
Copy link
Member

liggitt commented Feb 25, 2015

https://github.com/GoogleCloudPlatform/kubernetes/pull/4591/files#diff-24507fbfb739669903cc0ecbeb8769a5R77 is an example of what has to be done currently to create a secret

@liggitt
Copy link
Member

liggitt commented Feb 25, 2015

I imagine a kubectl command that supports these use cases:

  1. Create a secret with specified keys mapped to contents of specified files
  2. Create a secret with specified keys mapped to data provided on the command line
  3. Create a secret with a set of globbed files, using the filenames as keys

@pmorie
Copy link
Member Author

pmorie commented Feb 25, 2015

@liggitt And presumably a switch to say whether a particular thing should be base64 encoded, yes?

@liggitt
Copy link
Member

liggitt commented Feb 25, 2015

@pmorie I thought secrets always had to be base-64 encoded

@pmorie
Copy link
Member Author

pmorie commented Feb 25, 2015

@liggitt they do but some users may have pre-encoded artifacts they want to
use for whatever reason

On Wed, Feb 25, 2015 at 2:42 PM, Jordan Liggitt notifications@github.com
wrote:

@pmorie https://github.com/pmorie I thought secrets always had to be
base-64 encoded


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@bgrant0607 bgrant0607 added area/usability area/kubectl priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. and removed team/cluster labels Feb 27, 2015
@bgrant0607
Copy link
Member

This is config generation, similar to kubectl run-container and kubectl expose. The same pattern would work for this.

@pmorie
Copy link
Member Author

pmorie commented Mar 2, 2015

@erictune @thockin fyi

@derekwaynecarr
Copy link
Member

@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

@erictune
Copy link
Member

I wanted this last week. Looking forward to it.

@bgrant0607
Copy link
Member

This would be great.

Per #7311 , it should be possible to invoke this via library call also, not just kubectl command.

@joltup
Copy link

joltup commented May 25, 2015

+1...this is so necessary!

@derekwaynecarr
Copy link
Member

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

@thockin
Copy link
Member

thockin commented May 31, 2015

It becomes A triage issue - do we think the UX is bad enough that this is
necessary? At a glance I feel probably not, but not strongly so.

On Sun, May 31, 2015 at 12:14 PM, Derek Carr notifications@github.com
wrote:

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


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@thockin thockin added this to the v1.0-candidate milestone May 31, 2015
@thockin
Copy link
Member

thockin commented May 31, 2015

I'll flag this a a 1.0 candidate, but I don't think it will fly.

@derekwaynecarr
Copy link
Member

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

On May 31, 2015, at 4:42 PM, Tim Hockin notifications@github.com wrote:

I'll flag this a a 1.0 candidate, but I don't think it will fly.


Reply to this email directly or view it on GitHub.

@pmorie
Copy link
Member Author

pmorie commented May 31, 2015

I shoulda done something for this already :-/
On Sun, May 31, 2015 at 4:47 PM Derek Carr notifications@github.com wrote:

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

On May 31, 2015, at 4:42 PM, Tim Hockin notifications@github.com
wrote:

I'll flag this a a 1.0 candidate, but I don't think it will fly.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@bgrant0607
Copy link
Member

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.

@bgrant0607
Copy link
Member

Previous attempt to do something in this space was #7975.

@bgrant0607 bgrant0607 added priority/backlog Higher priority than priority/awaiting-more-evidence. and removed priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Jun 1, 2015
@bgrant0607
Copy link
Member

More generally, I'd be happy to have support for "experimental" commands in kubectl.

I'll take a look at bundle-secret.

@pmorie
Copy link
Member Author

pmorie commented Oct 16, 2015

+1 to stash

🏆

@thockin
Copy link
Member

thockin commented Oct 16, 2015

I still like "new" as the creation (but that opens the door for much more
discussion) and confide or grant as the way to assign to an SA.

Maybe I'm just wrong and "create" is the in-wall plumbing, "new" is exposed
plumbing, and "confide" or "secret" or "stash" is porcelain.

On Fri, Oct 16, 2015 at 11:01 AM, Paul Morie notifications@github.com
wrote:

Bikeshedding lvl 999:

I actually like confide and whisper better than divulge or reveal


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@thockin
Copy link
Member

thockin commented Oct 16, 2015

What about "deposit"? as in to a vault. Or "escrow"? Nah. "confide" or
"secret" have connotations that work. "stash" is pretty generic, it might
as well be "store" or "hold". "guard"?

On Fri, Oct 16, 2015 at 11:08 AM, Tim Hockin thockin@google.com wrote:

I still like "new" as the creation (but that opens the door for much more
discussion) and confide or grant as the way to assign to an SA.

Maybe I'm just wrong and "create" is the in-wall plumbing, "new" is
exposed plumbing, and "confide" or "secret" or "stash" is porcelain.

On Fri, Oct 16, 2015 at 11:01 AM, Paul Morie notifications@github.com
wrote:

Bikeshedding lvl 999:

I actually like confide and whisper better than divulge or reveal


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@pmorie
Copy link
Member Author

pmorie commented Oct 16, 2015

I'm afraid the trophy has already been awarded @thockin

@pmorie
Copy link
Member Author

pmorie commented Oct 16, 2015

hrm

@pmorie
Copy link
Member Author

pmorie commented Oct 16, 2015

I like deposit pretty well, actually.

@derekwaynecarr
Copy link
Member

vault uses read/write - https://vaultproject.io/docs/commands/read-write.html

@bprashanth
Copy link
Contributor

I like deposit pretty well, actually.

wait no, i like bury.
I kid I kid.

@ncdc
Copy link
Member

ncdc commented Oct 16, 2015

I just had the same thought re bury, ha...

@bgrant0607
Copy link
Member

secret would be the most obvious by far, and is a verb. Hopefully enough people have seen period British TV shows. Can we stop bikeshedding and just go with that?

new is taken for another purpose: #14294

@pmorie
Copy link
Member Author

pmorie commented Oct 16, 2015

@bgrant0607 +1 to picking a name and moving on. secret is fine with me.

@liggitt
Copy link
Member

liggitt commented Oct 16, 2015

secret would be the most obvious by far, and is a verb. Hopefully enough people have seen period British TV shows. Can we stop bikeshedding and just go with that?

jolly good

@pmorie
Copy link
Member Author

pmorie commented Oct 16, 2015

@derekwaynecarr
Copy link
Member

*secrets away to write a CLI command...

@ncdc
Copy link
Member

ncdc commented Oct 16, 2015

@derekwaynecarr now that we've settled on the name, would it be worth circling back here with an updated set of usage examples?

@thockin
Copy link
Member

thockin commented Oct 16, 2015

@derekwaynecarr
Copy link
Member

@ncdc - will comment with an updated set of usage patterns.

@derekwaynecarr
Copy link
Member

This is what a first PR would look like:

Create an opaque secret based on a file or directory
Usage:
  kubectl secret make NAME [options]

Examples:
  // Create a new secret named my-secret with keys for each file in folder "bar"
  $ kubectl secret make my-secret --from-file=path/to/bar

  // Create a new secret named my-secret with specified keys instead of names on disk
  $ kubectl secret make my-secret --from-file=key1=~/path/to/somefile --from-file=key2=~/path/to/someotherfile

  // Create a new secret named my-secret with specified literal values
  $ kubectl secret make my-secret --from-literal=key1=value1

Create a dockercfg secret with specified options
Usage:
  kubectl secret make-dockercfg NAME [options]

Examples:
  // Create a new secret named my-secret for use with a Docker registry
  $ kubectl secret make-dockercfg my-secret --email=jdoe --password=xyz --username=jdoe

It appears to meet the semantics @bgrant0607 expressed here:
#4822 (comment)

It appears to satisfy the desires of @thockin as understood here:
#4822 (comment)

It uses --from-file instead of source-file since we appear to use that somewhere in the project that cannot support a key=value pair.

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
$ oc secrets add serviceaccount/sa-name secrets/secret-name --for=pull,mount.

Open for debate if you want:

[1] $ kubectl grant serviceaccount/sa-name --from=secrets/secret-name 
[2] $ kubectl secret add ...
[3] $ kubectl secret grant ...

Please ack if you are good on kubectl secret make above and will submit PR when done.

@ncdc
Copy link
Member

ncdc commented Oct 16, 2015

If you do --from-file=key1=/path/to/dir is that a validation error because you're trying to assign a directory to a single key?

@derekwaynecarr
Copy link
Member

@ncdc - yes, need to check if we do that in oc

On Friday, October 16, 2015, Andy Goldstein notifications@github.com
wrote:

If you do --from-file=key1=/path/to/dir is that a validation error
because you're trying to assign a directory to a single key?


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@smarterclayton
Copy link
Contributor

-1 on the cute proposals - our job is not to reach for a thesaurus, it's to
establish clear lines of meaning between the concept (secret) and the
interaction mechanism.

The reason why the "command noun verb " shows up in a lot of places
is that new users often go looking for concepts (or see references to them
and try to find them in other places). Few users, wanting to provide a
secret to the platform, would jump to "confide" unless they were of a
particularly literary bent. Also, not all generic verbs are truly
generic. We've already bent "expose" in OpenShift because it applies to
pods (as a service) or a service (as a route or ingress). The overlap of
use creates additional flags (confusing, as David notes), or leads to
deeper hierarchy (kubectl new , which fits for many users, but then
results in harder shortcuts). The "concept command" encapsulates common
use cases with the concept, which is easy for a new user to locate (if i
want to work with secrets maybe i should run kubectl secrets -h) and easy
to reference for future (hey, I created a secret, if I want to use it maybe
I should go back).

Interactions with secrets are rarely one touch. The three most likely are
"grant" (which has common overlap with policy, so would at some point need
to support both secrets or policy), "mount as volume" (which has common
overlap with PVC), or "export". Both grant and mount as volume are likely
the immediate follow ups to a request to create a secret (and in fact, most
users would probably prefer a single action that creates a secret and
mounts it or shares it). It's hard to predict every interaction that could
exist in the future with secrets (use secret with a build, or a third party
integration).

I'm not in love with the "concept command" as a top level... but generic
verbs have their limits, and we should be able to recognize when a generic
verb is insufficient.

On Fri, Oct 16, 2015 at 2:20 PM, Prashanth B notifications@github.com
wrote:

I like deposit pretty well, actually.

wait no, i like bury.
I kid I kid.


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@derekwaynecarr
Copy link
Member

@smarterclayton - can you comment on the result I proposed "kubectl secret"
as parent command and "kubectl secret make" as opaque secret subcommand,
and "kubectl secret make-dockercfg" as the type specific secret syntax? I
think it aligns with where discussion ended, and addresses @thockin
critique on oc secrets use of arguments where flags were preferred.

On Friday, October 16, 2015, Clayton Coleman <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

-1 on the cute proposals - our job is not to reach for a thesaurus, it's to
establish clear lines of meaning between the concept (secret) and the
interaction mechanism.

The reason why the "command noun verb " shows up in a lot of places
is that new users often go looking for concepts (or see references to them
and try to find them in other places). Few users, wanting to provide a
secret to the platform, would jump to "confide" unless they were of a
particularly literary bent. Also, not all generic verbs are truly
generic. We've already bent "expose" in OpenShift because it applies to
pods (as a service) or a service (as a route or ingress). The overlap of
use creates additional flags (confusing, as David notes), or leads to
deeper hierarchy (kubectl new , which fits for many users, but then
results in harder shortcuts). The "concept command" encapsulates common
use cases with the concept, which is easy for a new user to locate (if i
want to work with secrets maybe i should run kubectl secrets -h) and easy
to reference for future (hey, I created a secret, if I want to use it maybe
I should go back).

Interactions with secrets are rarely one touch. The three most likely are
"grant" (which has common overlap with policy, so would at some point need
to support both secrets or policy), "mount as volume" (which has common
overlap with PVC), or "export". Both grant and mount as volume are likely
the immediate follow ups to a request to create a secret (and in fact, most
users would probably prefer a single action that creates a secret and
mounts it or shares it). It's hard to predict every interaction that could
exist in the future with secrets (use secret with a build, or a third party
integration).

I'm not in love with the "concept command" as a top level... but generic
verbs have their limits, and we should be able to recognize when a generic
verb is insufficient.

On Fri, Oct 16, 2015 at 2:20 PM, Prashanth B notifications@github.com
wrote:

I like deposit pretty well, actually.

wait no, i like bury.
I kid I kid.


Reply to this email directly or view it on GitHub
<
#4822 (comment)

.


Reply to this email directly or view it on GitHub
#4822 (comment)
.

@smarterclayton
Copy link
Contributor

Yes I'm ok with the current syntax at a high level.

verb added a commit to verb/kubernetes that referenced this issue Oct 29, 2015
This also includes a script to generate secrets configuration to support
these examples until kubernetes#4822 is resolved.
@zmerlynn zmerlynn mentioned this issue Oct 29, 2015
15 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubectl area/security area/usability kind/feature Categorizes issue or PR as related to a new feature. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Projects
None yet
Development

No branches or pull requests