Provide the OIDC token of the ContainerSource as a volume

[creydr]

Problem

As the Eventing OIDC feature track describes, the ContainerSource controller will add a volume to its managing container, which contains the token for authentication.
This will be a token for the ContainerSources identity (from .status.auth.serviceAccountName) and issued for the sinks audience (.status.sinkAudience).
The token will not be injected as a env var for security reasons and as it would not be refreshable without a pod restart.
The ContainerSource controller will take care of the token handling & refreshing.

For the ContainerSource controller, this means:

• when the sink has no audience defined:
  • no change in behavior
• when the the sink has an audience defined:
  • create a secret containing a JWT for the container source
  • mount this secret as a volume into the referencing container as a volume to /oidc/token
  • take care about token renewals and updates of the secret

Additonal Information

• requires Provide a library for OIDC token management #7175
• requires Support auto generation of ContainerSource identity service account and expose in AuthStatus #7228

[JRS296]

Hello there, I would love to help out, can you tell me more on what needs to be done? @creydr

[creydr]

Hello @JRS296,
Thanks for helping with this.
A good starting point for the OIDC topic is in general the Eventing OIDC feature track document. There you can see, that each source needs to have their own identity, which is exposed in their status (for the container source done in #7228).
The reconciler of the container source then needs to generate a JWT for this identity and the audience of the container sources sink. This JWT then needs to be saved in a secret and the secret mounted into the container sources container under /oidc/token. The controller needs also to take care about the renewals of the JWT (and updates of the secret).

Alternatively we could have simply created a service account token secret, and let the API server take care about the token management, but since this will only expose long lived tokens, we use the Kuberntes TokenAPI to get a time bound token (#7175).

A good starting point is probably the controller for the container source in pkg/reconciler/containersource. There you would need to request a Token from the OIDC library (#7175), create a secret with this token and mount it to the container sources deployment (containersource.MakeDeployment()).
The tricky part is probably more, how the token gets refreshed periodically (and the secret updated). For this suggestions on the approach are highly welcome.

This also relates to #7323 which has to achieve something similar and thus the logic for the token & secret update should be reusable.

Does this help?

P.S.: #7175 and #7228 needs to be done first

[JRS296]

Sounds good 👍
I will look into the aforementioned issues, and will try to deduce a way to handle re-usability for #7323. Will get started shortly.

[creydr]

Hi @JRS296,
I am putting this back into "Draft" status, as this probably can be done in #7323 (containersource uses a sinkbinding under the hood). I didn't see this initially, as I was not aware of the implementation details of the container source.
If this will be needed anyhow and this issue is ready to be worked on, I'll put it back into "Ready".
I am really sorry for the confusion

[JRS296]

Oh that's alright @creydr 👍

[creydr]

Done via #7444