We'll want commands to generate secrets for kubernetes auth and arbitrary user secrets (e.g., SSL keys). What would you expect those commands to look like?

cc @jlowdermilk

@bgrant0607, I think kubernetes auth/user secrets should just contain a kubeconfig serialization. We already support loading kubeconfig from arbitrary []byte data: pkg/client/clientcmd/loader.go.

I think @bgrant0607 was suggesting that we will need something like kubectl secrets create-kubeconfig and kubectl secrets create-sshkey and kubectl secrets create-opaque.

We'll want commands to generate secrets for kubernetes auth and arbitrary user secrets (e.g., SSL keys). What would you expect those commands to look like?

I don't know if all secret types are worthy of having their own commands. If the files that are used to store them are tight (only contain the relevant information) and well understood (ssl keys), then the basic kubectl secrets create (bundle?) is probably sufficient. Some less well known files or files that contains lots of extraneous information are probably worth having separate commands for.

.dockercfg files and .kube/config files can contain credentials for connecting to many different systems, so I'd want to provide commands that can help guide a user down the path of making a focused secret.

I see these:

kubectl secrets create NAME SOURCE [SOURCE ...] --secret-type=
  Where source is a file or directory.  I'd like to see this with auto-discovery based on SOURCE name/content.  (A .dockercfg file could become a docker config secret, a single kubeconfig file could become a kubeconfig secret)

kubectl secrets create-dockercfg NAME --docker-username= --docker-password --docker-email --docker-server

kubectl secrets create-kubeconfig NAME SOURCE --credentials-context=<name of context in source to use for flattening and minification>
    This command is different than "create" because it understands the kubeconfig file sufficiently to flatten it and conditionally minify it and provides an option for the user to specify usage with a non-default context.

Everywhere else, we use -f for the file, though everywhere else, the files contain API resources.

This is essentially a config generator. It should be versioned. Did you consider using generator.go?

This is essentially a config generator. It should be versioned. Did you consider using generator.go?

I'm not familiar with that file.

find . -name "generator.go" | wc -l
0

Maybe this one instead: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/generate.go?

I'm against generating a name for an object that will later be referenced. Secrets aren't cattle, they're pets. You care about exactly which one you're using and you need to be able to reference that particular one to get the behavior you want.

It should be versioned.

Just so I'm sure I understand correctly, you'd like me to use the external type package to build up the secret?

@deads2k see: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/generate.go

@bgrant0607 is saying that the generation itself needs to be versioned. Otherwise people will take a dependency on your implementation of generating the secret, and you will break them if you change that implementation. See https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/service.go

for a concrete example.

kubectl secrets create will create too much confusion with respect to kubectl create secret, so we need to come up with different syntax. The convention needs to be documented (#6797), but it's VERB or VERB NOUN, not the other order. There are some exceptions to this (most notably kubectl config), but let's not add any new ones.

Our other generators, run-container (which we plan to rename to just run) and expose, are just verbs.

I'll ponder alternative syntax.

With respect to generate.go (sorry about the misspelling) and generator versioning: Specifically, for our internal package manager, our generator became virtually unchangeable due to the massive number of dependencies on its precise behavior. We had to spawn new "versions" (with new names) in order to change it.

I could imagine something like kubectl make dockercfg-secret -f ... (all other commands (that I'm aware of) take file input from files specified by a -f flag). The new make verb would be a generic generator invoker. The noun would be the name of a generator. We could default the version to the latest version of that generator, but would encourage the user to specify the version if put into a script, much as we had to specify --api-version in all scripted uses of kubectl templates.

If you didn't want to bite off the more generic mechanism (though it doesn't sound too hard), something like kubectl push-dockercfg -f ... would be acceptable for now (though I'd like something that wouldn't be confused with docker push).

It needs to be possible to invoke the library directly rather than execute the kubectl command (#7311).

Also, we'll want to be able to invoke this mechanism declaratively. I'm fine with starting with an imperative command, but imagine doing kubectl create -f <directory>. I'd want it to generate and create the necessary secrets.

I guess kubectl make-dockercfg-secret -f ... could work, if a little long.

Another generator example:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/kubectl/cmd/run.go

Perhaps change to ""?

changed.

I left a few comments on the last commit-- nothing too major.

I'm not able to devote the time this deserves, so I'm closing. I'll take these comments into account when I have time to submit it again.