Support "Pod Service Account Token for Image Pulls" for Secretless authentication/pull

[3deep5me]

Is your feature request related to a problem? Please describe.
Currently its not possible to use Kubernetes Service Account Tokens to authenticate to Harbor - instead you have long life tokens which are "insecure" and hard to maintain.

Describe the solution you'd like
Use of a kubelet-credential-provider (https://kubernetes.io/docs/tasks/administer-cluster/kubelet-credential-provider/) in combination with Service Account Token for Image Pulls to authenticate to Harbor with short-life tokens on Service level.

Describe the main design/architecture of your solution
(we can also throw everything out the window i'm fully open to other ideas)

1. We need a possibility to verify Kubernetes Service Account Tokens
   1.1 I propose to use the same oidc-workflow which vault/bao uses: Use Kubernetes for OIDC authentication
   1.2 I'm not sure but maybe this is already more or less possible with the current Harbor OIDC-Integration - maybe there are only some minor changes needed
   1.3 Maybe changes in the UI/API would be needed - to show the KSAT not as a User instead as a "federated Robot"
2. We need to write a kubelet-credential-provider
   2.1 The Provider tests the Service Account Token to authenticate to Harbor and then passes it to kubelet
   2.2 Similar Example

Describe the development plan you've considered
This needs help.

Additional context
Not sure if we really need to use the KSAT to authenticate to Harbor for image-pulls or maybe a Token exchange is better. (Provider Plugin uses the KSAT to get/generate a short-life image-pull-token which is then used by the kubelet) I think cleaner would be to use the KSAT directly - but i'm not sure how big this change would be.

[3deep5me]

Probably it makes more sense that the kubelet credentials provider authenticate via oidc and then uses the https://demo.goharbor.io/#/user/setCliSecret endpoint to get a pull-secret.

[Vad1mo]

Like the idea: There are a few interesting implementations out there to get started with.

• https://github.com/hegerdes/kubelet-static-credential-provider
• https://github.com/simonostendorf/kubelet-credential-provider-vault
• https://github.com/thomasmey/artifactory-credential-provider
• https://github.com/kubernetes/cloud-provider-aws/tree/master/cmd/ecr-credential-provider

I think the best option would be to create robot accounts, as this adds transparency.

[3deep5me]

Yeah, that's sounds good. The Robot account could be created on first login. Currently AFAIK Harbor only supports one OIDC Provider. I think the hard part would be to implement additional OIDC-Federation for Kubernetes Service Accounts into Harbor to validate the kubernetes service account tokens. There is this OIDC Federation V1 spec which would be probably the way to go for that. The Vault-Provider you mentioned looks really good to me. Because it's using the new KSAT feature.

[Vad1mo]

This is what it might look like:

1. For each k8s cluster, the Harbor Admin creates a System Robot Account
   (TBD, variation, the system robot account might be able to create child robot accounts)
   (Maybe the robot account can accept discover endpoint, or accept pub certs.)
2. The Parent robot account can accept JWT.
3. Once the JWT arrives, a child robot account is created per namespace or pod

What I am after is the option to Crete kind of pseudo robot accounts so that it is all visible in the auditlogs.

I don't understand all the details, so I am currently speculating that the easies way would be to create a separate logic, endpoints and UI settings. to have multiple k8s clusters. I think it will be more difficult to incorporate it into the current code

[3deep5me]

This sounds like a really good idea. Would you see this on Project or Admin level? Or maybe both?
Also maybe something like a Auto role assigner for the parent-robot would make sense.

[Vad1mo]

An additional important aspect is to make sure that in setups with multiple teams and projects, that only the respective team can pull their images into their namespace.

[enj]

If possible, it is recommended to use the https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1 API instead of plain JWT validation. Token review correctly handles revocation and does not require a published JWKs endpoint.

[3deep5me]

Thanks @enj for your reply - this is a good thing to mention - especially if short life tokens are not enabled in kubernetes. The problem I see with the token request API is, that the kubernetes API needs to be reachable to validate the token, this is not always the case. The JWK could be also manually exchanged and works without access to the kube-api if I'm correct.

[enj]

You could certainly support both approaches. In some environments access to the Kube API is easier than getting access to the JWKs endpoint and issuer URL (having a process to publish and rotate public keys across a fleet of clusters is non-trivial to build for a large fleet of clusters - but all the major cloud providers do this for you).

[reasonerjt]

Hi, thanks for the issue.

I took a quick look in the link:
https://kubernetes.io/docs/tasks/administer-cluster/kubelet-credential-provider/#service-account-token-for-image-pulls

It's still in alpha state. I'll do more investigation but I think we'll wait for the feature to be more mature (GA, beta) to start to work on it.

[Vad1mo]

If possible, it is recommended to use the https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-review-v1 API instead of plain JWT validation. Token review correctly handles revocation and does not require a published JWKs endpoint.

Does it also work (and how) in toplogies where Harbor is running on different k8s clusters or in scenarios where harbor has no connectivity to the K8s API endpoint?