Convenience for generating API keys for automation

[jessesuen]

Proposed Feature

Kargo should have a convenience for creating long-lived "API keys" for interacting with Kargo API. This should be manageable from the UI either as a separate tab, or incorporated into the existing Roles tab.

Motivation

It will be desired for some automated systems to interface with Kargo API. For example, I would like for my CI system to refresh a Warehouse as soon as it pushed an image is pushed so that Kargo knows about it right away.

Suggested Implementation

"API Keys" would really just be Kubernetes ServiceAccount Bearer Tokens under the covers. The tokens would be bound to Kargo Roles (which are just K8s ServiceAccounts). This feature is simply a UI & API convenience for creating a ServiceAccount token Secret:

https://kubernetes.io/docs/concepts/configuration/secret/#serviceaccount-token-secrets

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token

And then returning data.token to the user.

Other considerations

• Alternative to this approach, we may instead consider using TokenRequest API to achieve the use case.

• ServiceAccount tokens do not have expiry. I propose that we add our own expiry metadata to the secret, and a controller will ensure that the Secret is purged or invalidated after the expiry.

[krancour]

@jessesuen if the token we issue is a k8s bearer token, then we're talking about "client auth" to the API Server?

https://github.com/akuity/kargo/blob/08b394f6a060e20b90e29499a8717cf9094c8a5c/internal/api/option/auth.go#L397-L406

One possible issue with this is that we don't really get any information about the principal in that case, which makes audit logs incomplete, but we may be able to figure something out.

[jessesuen]

if the token we issue is a k8s bearer token, then we're talking about "client auth" to the API Server?

That's correct. Yes, service account namespace/name is in the JWT and is available to the webhook, and API server, so I think we have sufficient information to enrich the audit events.

[jessesuen]

Another requirement: since I intend to use this from my CI system, kargo CLI should accept an env var to use this token.

[krancour]

That's correct. Yes, service account namespace/name is in the JWT and is available to the webhook, and API server, so I think we have sufficient information to enrich the audit events.

I should have been more clear. I knew the info would be there. The thing that's a little bit of a problem is unless we have a way to validate the token ourselves, we can't trust its claims. But I still think we'll be able to figure something out.