Kustomize Secret Generator Plugins KEP
1,470 views
Skip to first unread message
Jeffrey Regan
Feb 13, 2019, 8:15:21 PM2/13/19
to kubernetes-sig-cli
The Kustomize Secret Generator Plugins KEP was discussed in the 2019-Feb-13 sig-cli meeting.
The KEP restores popular functionality recently lost in kustomize.
If there are no objections, we’d like to merge the KEP as implementable on Feb 18 (next Monday).
The KEP describes using GoLang plugins; the tl;dr is that all plugins must be .so files in a fixed directory (e.g. ~/.config/kustomize_plugins).
PTAL. If there are no strong objections, we’d like to accept the KEP as implementable via lazy consensus on Monday, since users need some options here for secrets.
The KEP restores popular functionality recently lost in kustomize.
If there are no objections, we’d like to merge the KEP as implementable on Feb 18 (next Monday).
background:
kustomize users want a means to generate k8s Secret objects in the context of a `kustomize build` command using rules specified in a kustomization file.
Users of kustomize 1.0.x could specify, in the kustomization file, the path to any executable to run as a subprocess to generate a secret during a build command. This was deemed unsafe as kustomize also allows a user to download and interpret kustomization files at build time, and a kustomization file that was good on Monday might become evil on Tuesday.
In kustomize 2.0.x, the only way to generate a secret is to read data from disk, a process that raises questions about how long the secret is on disk and who can read it during that time. These questions were the reason build-time execution was provided in 1.0.x.
kustomize users want a means to generate k8s Secret objects in the context of a `kustomize build` command using rules specified in a kustomization file.
Users of kustomize 1.0.x could specify, in the kustomization file, the path to any executable to run as a subprocess to generate a secret during a build command. This was deemed unsafe as kustomize also allows a user to download and interpret kustomization files at build time, and a kustomization file that was good on Monday might become evil on Tuesday.
In kustomize 2.0.x, the only way to generate a secret is to read data from disk, a process that raises questions about how long the secret is on disk and who can read it during that time. These questions were the reason build-time execution was provided in 1.0.x.
The KEP in question wants to reintroduce the idea of specifying a secret generation command to run in a kustomization file, but this time restrict the command to be a ‘plugin’, thus avoiding the arbitrary command risk.
alternatives discussed:
alternatives discussed:
Two options were discussed for a secret generator "plugin" - kubectl plugins and GoLang plugins.
A kubectl plugin is any executable on your $PATH whose name begins with ‘kubectl-’. When one enters the command `kubectl foo bar`, where foo is a non-native command, kubectl will attempt to find and execute the program `kubectl-foo-bar` in a subprocess (this emulates command nesting). The canonical doc explains how parsing of command arguments and flags, how one can list all plugins, etc.
A GoLang plugin is a Go package compiled with -buildmode=plugin, to create a .so file. Any running Go program can dynamically load the library from any file path as an object, then cast it to a particular type - details in the canonical doc. Kubectl plugins as a concept were offered before GoLang plugins were available.
A kubectl plugin is any executable on your $PATH whose name begins with ‘kubectl-’. When one enters the command `kubectl foo bar`, where foo is a non-native command, kubectl will attempt to find and execute the program `kubectl-foo-bar` in a subprocess (this emulates command nesting). The canonical doc explains how parsing of command arguments and flags, how one can list all plugins, etc.
A GoLang plugin is a Go package compiled with -buildmode=plugin, to create a .so file. Any running Go program can dynamically load the library from any file path as an object, then cast it to a particular type - details in the canonical doc. Kubectl plugins as a concept were offered before GoLang plugins were available.
The KEP describes using GoLang plugins; the tl;dr is that all plugins must be .so files in a fixed directory (e.g. ~/.config/kustomize_plugins).
PTAL. If there are no strong objections, we’d like to accept the KEP as implementable via lazy consensus on Monday, since users need some options here for secrets.
Phillip Wittrock
Feb 13, 2019, 11:16:28 PM2/13/19
to Jeffrey Regan, kubernetes-sig-cli
+1. Evolution is better than stagnation. I support moving forward with go plugins for iteration 1. We can look at alternatives for iteration 2 if there is sufficient demand.
We should check if an API review is necessary for this.
- Phil
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/093ab0bb-e09e-466e-a7a9-ea62f1484244%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages