Serving webhook should allow changing the automountServiceAccountToken to true

[saisree95]

What version of Knative?

1.9.2

Expected Behavior

A user should be allowed to set spec.template.spec.automountServiceAccountToken to true.

Actual Behavior

(error: services.serving.knative.dev "xxxxxx" could not be patched: admission webhook "validation.webhook.serving.knative.dev" denied the request: validation failed: must not set the field(s): spec.template.spec.automountServiceAccountToken)

Steps to Reproduce the Problem

Create a Service with spec.template.spec.automountServiceAccountToken to false. Change the automountServiceAccountToken to true and the issue will be reproduced.

[saisree95]

Similar issue is seen at https://github.com/knative/serving/issues/9127

[KauzClay]

Hey @saisree95 , it looks like this was done intentionally (see #11723 (comment)).

From what I understand, the default behavior for automountServiceAccountToken is true unless it was changed at an admin level on the cluster. Is there a reason you want to set it to true explicitly, rather than just removing the spec.template.spec.automountServiceAccountToken section entirely?

[Sidhardha95]

Hi @KauzClay ,

We are working on k8s CRDs which requires us to come with Operator for k8s CRDs. And we also have few services that sync k8s CRDs along with some default k8s resources too.

We are using Java fabric8 client do the syncing. And to do this we are providing access to a Service Account and we have been using Service account token to sync with k8s CRD(we are setting automountServiceAccountToken to true in serviceAccount).

But as per our security team , it is not recommended to set automountServiceAccountToken to true in service account instead the recommendation is to set it on Deployment or KSVC.

We tried to do this by removing automountServiceAccountToken in service account. But when we did that we did not set CRD sync not happening. And then we tried to set automountServiceAccountToken explicitly to true in KSVC , but thats when we ran into above problem.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[hernanDatgDev]

Hi @KauzClay, my team and I have run into the same validation issue and not just with this field but others as well. These fields are recommended by our security team and I can't configure them because of the validation rules. For example one of the other fields is spec.template.spec.securityContext.seccompProfile. I don't mind looking into this and creating a PR potentially but do you know who I can ask for some more guidance on why certain fields aren't allowed in the first place?

[hernanDatgDev]

/remove-lifecycle stale

[knative-prow]

@hernanDatgDev: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen
/remove-lifecycle stale

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.