Deprecate additional sidecar config options

[johnharris85]

Description

Once the ability to customize the sidecar and init containers is merged, there will be some existing 'band aid' configuration settings that can be deprecated, this is to track the high-level list (and maybe decide if / how / when to do those deprecations).

Annotations:

• kuma.io/sidecar-env-vars
• kuma.io/service-account-token-volume

[lahabana]

Sidecar injection will be released in 1.7 so can't do this before 1.9

[afzal442]

hi @lahabana, wanna contribute here.

Any help?

[lahabana]

Hey unfortunately it's a little too early to contribute this as our deprecation policy is to keep things around for 2 releases before we remove them. This is to enable users to migrate to the new way of doing things.

If you are looking for other simpler changes to do look at: good first issue Good for newcomers

[github-actions]

This issue was inactive for 30 days it will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant please comment on it promptly or attend the next triage meeting.

[rainest]

I'd actually encourage keeping this as a minimal fuss method of handling Pods with automountServiceAccountToken: false.

It's possible to handle these with ContainerPatch, but managing the annotation is easier than managing and attaching the separate resource. We can also add the annotation blindly on behalf of users in the Kong chart--doing so without Kuma in place is benign--but require an additional toggle to create ContainerPatch, since that CRD won't be available without Kuma and some installers lack permission to check for CRD availability. ContainerPatch as-is isn't viable for this either; it requires the json-patch EnsurePathExistsOnAdd option for safe use.

Edit: keeping this, or at least waiting longer than initially planned to drop it, is also good for cross-version compatibility. Dropping it quickly will mean we have a narrow range of chart versions compatible with still recent versions of Kuma, with later chart versions only compatible with Kuma releases after #4279. I don't think we can include both the annotation and patch, since including the patch with older versions will actually break them (it'll try, but fail to apply).

Another alternative is having Kuma request its own tokens, similar to what Istio uses. The TokenRequest API that leverages should be available by default on 1.20+ clusters. Using that negates the need to create a separate token and reference it in the patch/annotation, since Kuma can just create its own.

[github-actions]

This issue was inactive for 90 days. It will be reviewed in the next triage meeting and might be closed.
If you think this issue is still relevant, please comment on it or attend the next triage meeting.

[rainest]

Have there been any further thoughts on whether to keep or deprecate these fields? Releases are now up 2.0 there hasn't been any further discussion of plans or additional features to deprecate found.

[jakubdyszkiewicz]

Triage: We decided to close this issue and not deprecate the kuma.io/service-account-token-volume annotations as keeping them does not cost us much from the maintenance point of view.