Harden Job Pod Service Account RBAC Settings

[ihcsim]

The job pod should be updated to use the namespace default service account if none is specified by the user, following the Kubernetes Job model. By default, the pod should also run with spec.automountServiceAccountToken: false to NOT automatically mounted the service account credentials. Most job pod shouldn't need direct interaction with the Kubernetes API server. When it does, the pod should be using an ephemeral projected ServiceAccountToken.

[github-actions]

Thanks for opening this issue 👍. The team will review it shortly.

If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.

If you haven't already, please take a moment to review our project's Code of Conduct document.

[github-actions]

This issue is marked as stale due to inactivity. Add a new comment to reactivate it.

[Sagar2366]

@ihcsim can I work on this issue ?

[ihcsim]

@Sagar2366 the code change for this is relatively simple, but a number of example blueprints will need to be updated. E.g., this etcd blueprint assumes that the job pod uses a service account that has permission to run kubectl exec against etcd pods. In this example blueprint, it uses the controller's service account. Making this change will require updating the blueprints to use the podOverride argument, to provide a service account with the appropriate RBAC permissions.

Furthermore, due to its breaking change nature, it isn't something that we can roll out immediately. We will need to give the community sufficient notice before rolling out this change.

Let me know if you are still interested in working on it.

[Sagar2366]

@ihcsim thank you for the inputs.
I am still ramping up and trying to understand the project, so please guide me along the way as you're doing.
Yes, I am still interested to work on it.

[ihcsim]

@Sagar2366 Thanks again for your interest. @pavannd1 and I will go over how to handle this breaking change. I do think it's important that this gets fixed. Will keep you posted.

Meanwhile, you can try out Kanister on your local cluster following the installation instructions here. Then follow this short tutorial to see Kanister in action. (The tutorial uses a KubeExec Function, you may wanna try with KubeTask since it's directly relevant to this issue.)

[Sagar2366]

Sure @ihcsim.

[pavannd1]

To be discussed internally with downstream users.

[github-actions]

This issue is marked as stale due to inactivity. Add a new comment to reactivate it.

[github-actions]

This issue is closed due to inactivity. Feel free to reopen it, if it's still relevant.