[elasticsearch]: optionally disable SA token automount#1300
[elasticsearch]: optionally disable SA token automount#1300jmlrt merged 1 commit intoelastic:masterfrom equinix-ms:elastic-opt-mount-sa-token
Conversation
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
|
Hi devs, is there anything I can do to get this ball rolling? |
|
Rebased/cherry-picked to 7.14 |
|
Hi devs, I'd really like someone to take a look at this security fix. Is there anything I can do to get this fixed? |
|
@jmlrt any chance you could take a look at this PR? Looks like you are an active dev here, and I'd really like this feature at least considered 😉 |
jmlrt
left a comment
There was a problem hiding this comment.
Hi @jonkerj, sorry for the late answer.
This PR makes sense, however I have a few comments:
- unless cases where a change is only valid for a specific version, PR should be opened to master branch then Elastic handle the backport to the other branches
- the default value should be True to avoid a breaking change
|
💚 CLA has been signed |
|
Better late than never ;-) I've (re-)signed the CLA, fixed both things, and force pushed. Should be good now. |
|
jenkins test this please |
jmlrt
left a comment
There was a problem hiding this comment.
Some changes are required to make Black formatter happy in elastic+helm-charts+pull-request+lint-python/1093.
Can you run black elasticsearch/tests/elasticsearch_test.py?
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com>
|
done |
|
jenkins test this please |
|
@jmlrt : is there anything else I can do? |
|
Hi @jonkerj, sorry the PR is approved but CI tests are broken for now. |
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com>
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com>
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com>
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com>
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com> Co-authored-by: Jorik Jonker <jorik@kippendief.biz>
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com> Co-authored-by: Jorik Jonker <jorik@kippendief.biz>
ES has no direct interaction with the Kubernetes API, and as such, it does not need a mounted service account token in its pods. By disabling this automount, potential attackers cannot access the API on behalf/through the Pod. This commit allows users to opt out on SA token automount. It leaves the current behaviour unchanged, to avoid breaking things. Signed-off-by: Jorik Jonker <jorik.jonker@eu.equinix.com> Co-authored-by: Jorik Jonker <jorik@kippendief.biz>
Description of the change
It disables the automounting of the service account token in the pod. Elastic does not need this by itself. This commit disables it by default, but leaves it configurable if anyone needs to use it.
Benefits
By disabling the automount, potential attackers cannot access the Kubernetes API on behalf/through the pod.
Possible drawbacks
If anyone is using some sidecar or plugin to access the Kubernetes API, they will have to explicitly enable (
--set rbac.automountToken=true) the automount of the SA token in the values.Applicable issues
#1330
${CHART}/tests/*.py${CHART}/examples/*/test/goss.yaml