Containersource use OIDC identity of corresponding SinkBinding

[creydr]

Currently the Containersource creates a dedicated OIDC identity, while its corresponding SinkBinding does as well. Later the SinkBindings identity is used to create the token secret, which gets mounted into the SinkBinding and thus the Containersources deployment. This leads to having a token for another identity mounted in the containersource, as announced in the containersources .status.auth.serviceAccountName.

This PR addresses it and uses the SinkBindings .status.auth in the Containersources .status.auth

Hint for reviewers:

• 8ce890f reverts the change which was done to create and expose the OIDC service account for the containersource
• c5ed064 is the actual change
• 8c3affe adds an e2e test

Release Note

ContainerSource: use same OIDC identity as corresponding SinkBinding

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.18%. Comparing base (7e1c082) to head (c154504).
Report is 24 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7890      +/-   ##
==========================================
- Coverage   69.22%   69.18%   -0.04%     
==========================================
  Files         339      341       +2     
  Lines       19494    15816    -3678     
==========================================
- Hits        13494    10943    -2551     
+ Misses       5337     4200    -1137     
- Partials      663      673      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[creydr]

    wait.go:263: Service test-fwowbtfo/dls-fjdfpvwm, ip: 10.14.177.201
    wait.go:282: Endpoints for service test-fwowbtfo/dls-fjdfpvwm, got 1, want >= 1
    wait.go:304: Failed while waiting for service ready: an error on the server ("Internal Server Error: \"/apis/batch/v1/namespaces/test-fwowbtfo/jobs/dls-fjdfpvwm-readiness-check-cnjbkgpz\": the server is currently unable to handle the request") has prevented the request from succeeding (get jobs.batch dls-fjdfpvwm-readiness-check-cnjbkgpz)

Seems like an infra issue
/retest-required

[pierDipi]

/lgtm
/approve

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: creydr, pierDipi

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:

• OWNERS [creydr,pierDipi]

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