You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ability to generate Secrets using `exec` was removed in kustomize v2 because of security concerns
38
-
about allowing `kustomization.yaml`'s publishers to execute arbitrary commands on the
39
-
machines of any user who applies the `kustomization.yaml`.
38
+
about users kustomizing malicious `kustomization.yaml`s and thereby providing a path for `kustomization.yaml`'s
39
+
publishers to execute arbitrary commands on the machines of any user who applies the `kustomization.yaml`.
40
40
41
41
Example goal to enable:
42
42
43
-
- Alice wants to develop an Application requiring a shared Secret, and to deploy it on Kubernetes using gitops
44
-
- Alice wants her gitops deployment mechanism to pull the Secrets that it deploys from an
43
+
- Alice wants to develop an Application requiring a shared Secret, and to deploy it on Kubernetes using GitOps
44
+
- Alice wants her GitOps deployment mechanism to pull the Secrets that it deploys from an
45
45
remote source without writing the Secrets as files to local disk.
46
-
- Alice's organization configures the gitops deployment container to run kustomize in the cluster
46
+
- Alice's organization configures the gitops deployment container to run Kustomize in the cluster
47
47
and be capable of pulling Secrets from remote locations
48
48
- Alice writes her kustomization.yaml to use the generation options configured by her organization.
49
49
50
50
Example exploit to avoid:
51
51
52
52
- Alice wants to run a whitebox mysql instance on a test cluster
53
-
-Carl publishes a whitebox mysql `kustomization.yaml` on GitHub, with a SecretGenerator
54
-
that will read Alice's ~/.kube/config and send it to Carl's server by executing `sh`
55
-
will a script to generate some Secret
56
-
- Alice runs `kubectl apply -k https://github.com/carl/mysql` and has the credentials
57
-
of all of her Kubernetes clusters sent to Carl when the Secret is generated.
53
+
-Chuck publishes a whitebox mysql `kustomization.yaml` on GitHub, with a SecretGenerator
54
+
that will read Alice's ~/.kube/config and send it to Chuck's server by executing `sh`
55
+
will run a script to generate some Secret
56
+
- Alice runs `kubectl apply -k https://github.com/chuck/mysql` and has the credentials
57
+
of all of her Kubernetes clusters sent to Chuck when the Secret is generated.
58
58
59
-
See [692][execRemoval] for more details.
59
+
See [kubernetes-sigs/kustomize#692](https://github.com/kubernetes-sigs/kustomize/issues/692) for more details.
60
60
61
61
## Motivation
62
62
63
-
The ability to create Kubernetes Secrets generated by commands is a commonly requested user.
64
-
This is useful for use cases where the user doesn't want the Secrets to be appear decrypted
63
+
The ability to create Kubernetes Secrets generated by commands is commonly requested by users.
64
+
This is useful for use cases where the user does not want the Secrets to be appear decrypted
65
65
on disk before being applied to the cluster.
66
66
67
67
Examples:
@@ -70,89 +70,197 @@ Examples:
70
70
- Secrets sources are not stored locally, and need to be fetched from some remote location
71
71
- Secrets are generated using some function (e.g. private-keys)
72
72
73
-
**Note:** For the common targeted case, *the solution for generating the Secret already
74
-
exists as a command on the user's machine*. User's are not expected to require a
75
-
marketplace of solutions, rather instead they are expected to need to be able to
76
-
invoke the tools they already depend upon.
73
+
**Note:** For the target case, *the command for generating the Secret already exists as an executable on
74
+
the user's machine*. User's are not expected to want a marketplace of solutions, rather instead they are
75
+
expected to want to be able to invoke the tools they already use for addressing this task.
77
76
78
77
### Goals
79
78
80
-
- Enable users to generate Secrets using the tools they already have on their machines
81
-
- Require Alice to opt-in inorder for Carl to execute commands on her machine
82
-
- Support Linux / Mac / Windows platforms
79
+
- Enable users to generate Secrets using the tools they already use to do so
80
+
- Secure by default - Alice must configure her environment in an insecure manner and run the command in an
81
+
insecure way for it to be exploitable
82
+
- Support Linux / Mac / Windows OS's
83
83
84
84
### Non-Goals
85
85
86
-
-Enable an ecosystem of users authoring plugins and sharing them
87
-
- Reduce friction for publicly published whitebox `kustomization.yaml`s to generate Secrets
88
-
86
+
-Support an ecosystem of users (i.e. not centralized within a single organization) authoring plugins
87
+
and sharing them with one another.
88
+
- Eliminate all friction for publicly published whitebox `kustomization.yaml`s to generate Secrets
89
89
90
90
## Proposal
91
91
92
-
Re-introduce `exec` Secret generators, but require the executables to have a whitelisted prefix
93
-
and require a flag.
94
-
95
-
- Introduce a flag `--secret-generator-exec-prefix` defaulted to `kustomize-sg-`
96
-
- Introduce a flag `--enable-exec-secret-generator` defaulted to `false`
97
-
- Commands provided to generate Secrets *must* start with the prefix, or kustomize will exit 1
98
-
- The enable flag *must* be provided if an exec Secret Generator is specified, or kustomize will exit 1
99
-
- Command is executed from the `PATH` variable, it cannot be an absolute or relative path
100
-
- This is to prevent Carl from publishing a malicious generator with the kustomization.yaml and invoking it
101
-
- Users can override the prefix with a string value with `len(value) > 2` - e.g. `sg-`
102
-
- Min length is to prevent users from providing an empty value, which would allow arbitrary command execution
92
+
Re-introduce `exec` SecretGenerators, but with the following safeguards in place to address security concerns.
93
+
94
+
- Plugins must be explicitly enabled with a flag. If it is not enabled and is used, Kustomize will exit 1 without
95
+
running exec.
96
+
- This is to protect against the case where exploitable plugins are installed and used safely internally in an
97
+
organization.
98
+
- If exiting 1, Kustomize will first print the list of plugins exec commands that were not executed, and a message
99
+
about the flag.
100
+
- Executables are restricted to flag defined paths - defaulted a location that is empty by default. Users must install / symlink executables to this location.
|`enabled`|`--enable-plugins`| bool |`false`| Enable plugins. If set to `false` and plugins are specified by the `kustomization.yaml` (recursively), then Kustomize will print the plugins that would be run and exit 1. |
107
+
|`path`|`--plugin-path`|[]string |["`$XDG_CONFIG_HOME/kustomize/plugins/kvSources`", "`/usr/local/kustomize/plugins/kvSources`"]| List of relative or absolute paths to search for plugin actuators - e.g. for `exec` look for executables on these paths. For `go-plugins` look for `.so` files on these paths. Relative paths must are relative to the `kustomization.yaml` provided to the command. They are never not relative to the base `kustomization.yaml`s. |
108
+
109
+
### Example
110
+
111
+
#### Default Path
112
+
113
+
Note: `my-exec-plugin` exists at `$XDG_CONFIG_HOME/kustomize/plugins/kvSources/my-exec-plugin`
114
+
115
+
```yaml
116
+
secretGenerator:
117
+
- name: fromPlugins
118
+
kvSources:
119
+
- pluginType: exec
120
+
name: my-exec-plugin
121
+
args:
122
+
- anotherArg
123
+
- yetAnotherArg
124
+
```
125
+
126
+
```sh
127
+
$ kustomize build ./ --enable-plugins
128
+
```
129
+
130
+
#### Flag Defined Absolute Path
131
+
132
+
Note: `my-exec-plugin` exists at `/foo/kvSources/my-exec-plugin`
0 commit comments