Allow opt-out of service account token automounting

[gilles-gosuin]

Description

Two new Helm values have been introduced: automountServiceAccountToken and serviceAccount.automountServiceAccountToken.

The values have been willingly left commented out in the default values file and the template won't output anything if the value is not explicitly set, so that existing manifests are left unchanged. Opting out of the feature (or explicitly enabling it) requires the chart user to add the values in their values file.

Fixes #3982

Checklist

• [? ] Unit tests updated (are there any that are applicable to this change?)
• [x ] End user documentation updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gilles-gosuin / name: Gilles Gosuin (9602a82, fa0e184, 8c0ca55, 84d154c, c5e928f)

[k8s-ci-robot]

Welcome @gilles-gosuin!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @gilles-gosuin. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mloiseleur]

Hello @gilles-gosuin,

Thanks for taking the time to open this PR.

It's a good idea to disable automountServiceAccountToken on ServiceAccount.
And it should be the default, as recommended by many security scanners.

But, on Deployment, external-dns needs it.
Is there really a use case where it can be useful ?

[stevehipwell]

I can't see a use for this as Metrics Server needs the service account token to function correctly.

[gilles-gosuin]

Our use case is simple: we have corporate policies that mandate that the service account token automounting feature be disabled.

In order for external-dns to function properly, Helm users who disable automounting should manually mount the token in containers that need it using the extraVolumes and extraVolumeMounts values.

[stevehipwell]

@gilles-gosuin are you referring to ServiceAccount token volume projection?

[gilles-gosuin]

@gilles-gosuin are you referring to ServiceAccount token volume projection?

I am indeed

[stevehipwell]

@gilles-gosuin I can see the value in this for the ServiceAccount but I'm not convinced we need to support it on the Deployment given that we expect SA to Deployment to be a 1-2-1 relationship.

Also the key checking pattern is overkill for a boolean where we expect a specific behaviour. I think the value can be set to true by default and support being overridden.

[gilles-gosuin]

I can see the value in this for the ServiceAccount but I'm not convinced we need to support it on the Deployment given that we expect SA to Deployment to be a 1-2-1 relationship.

To put it all in context, I'm requesting this feature because Azure Defender checks for the flag on the Deployment and creates a Security Recommendation if it is not set to false. It does not check for the flag on the ServiceAccount that is assigned to the Pod. Having the possibility to set that flag in the Deployment would allow us to have a Defender-compliant external-dns simply by updating the Helm values.

Also the key checking pattern is overkill for a boolean where we expect a specific behaviour

That's the approach I initially took, then I realized it might not be backward-compatible in some "extreme" cases. You could have for instance, someone who's facing the same issue as I am (corporate policies mandating automounting to be turned off) and who embarked on writing a webhook to handle this on the fly. eg. if the flag is not set, set it to false and mount the token manually.

[stevehipwell]

@gilles-gosuin fair enough on the reason to support it on the Deployment, although it does seem a lot like security theater.

On the implementation side, the value key should be present and I can't see a reason why it can't be explicitly set. Alternatively the value key could be left empty and a with block could be used.

[gilles-gosuin]

@gilles-gosuin fair enough on the reason to support it on the Deployment, although it does seem a lot like security theater.

It sure does indeed (and it sure is...)

On the implementation side, the value key should be present and I can't see a reason why it can't be explicitly set. Alternatively the value key could be left empty and a with block could be used.

Unfortunately, the default assumed by k8s is true; a with block will not output anything when the value is empty or false and this is not what we want.

I explained the reason why it might be problematic if a default is set in the Chart's values.yaml:

You could have for instance, someone who's facing the same issue as I am (corporate policies mandating automounting to be turned off) and who embarked on writing a webhook to handle this on the fly. eg. if the flag is not set, set it to false and mount the token manually.

Forcing a default value (which could only be true or it will definitely break most users) will modify existing manifests. This is probably NOT a major hurdle but it might break some corner use cases, as I tried to illustrate above.

[stevehipwell]

@gilles-gosuin good point about the with behaviour. I think I'd still like to see the key defined but empty for consistency; a string test would allow for testing between false and null. I agree that in general terms unset but true is different to explicitly true, although in this case I think there is a case for it to be explicitly true.

[gilles-gosuin]

So if I understand correctly:

• default value: empty
• if the value is empty, nothing gets output to the manifests
• if the value is true or false, it gets output to the manifests

Is that what you have in mind?

[mloiseleur]

/ok-to-test

[gilles-gosuin]

I added the default (empty) values for both flags and kept the "hasKey" checks in the templates, as I can't think of a more idiomatic way of doing what's required by the specs you described.

[mloiseleur]

/lgtm

[mloiseleur]

/lgtm

[stevehipwell]

@gilles-gosuin could you please add an entry to the CHANGELOG for this PR.

/label tide/merge-method-squash

[stevehipwell]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stevehipwell

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• charts/OWNERS [stevehipwell]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment