feat: add service accounts options to sso

[ldgriswold]

Description

This enables support for service account roles in keycloak for client credentials type grants
...

Related Issue

Fixes #851

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide followed

[ldgriswold]

From https://www.keycloak.org/docs-api/21.1.1/rest-api/#_clientrepresentation

[ldgriswold]

Example config: https://github.com/defenseunicorns-partnerships/wfapi/blob/feature/sso/chart/templates/uds-package.yaml

Resulting keycloak client:

[ldgriswold]

Pushed a fix due to a trick in the system:

apiVersion: uds.dev/v1alpha1
kind: Package
metadata:
  name: {{ include "wfapi.fullname" . }}
spec:
  sso:
    - name: wfapi-creds
      clientId: wfapi
      standardFlowEnabled: false
      publicClient: true
      serviceAccountsEnabled: true #TODO: Add this to UDS Core
      attributes:
        oauth2.device.authorization.grant.enabled: "true"

Was allowing a public client to be created, now pepr catches the error:

[bburky]

I need to test this, but I think this is PR is fine.

We (@rjferguson21 ?) can do a follow up PR to implement a hypothetical authz: or something that is the same as authserviceServiceSelector: but only Istio JWT authn/zuthz, no authservice. This field would sit beside these other options.

This PR should work today for grant=client_credentials auth to a (mission app) workload that does internal JWT validation. I really don't want to encourage apps to do their own JWT validation and crypto though, so adding authz: would let Istio do the JWT auth and more safely implement grant=client_credentials auth workload with automatic Istio JWT validation. I would argue Keycloak service accounts primarily make sense for out-of-cluster machine-to-machine clients connecting to an in-cluster workload.

Very similarly, we could support istio authz on users using OAuth Device Flow to connect to an in-cluster workload with the same authz: field (generates the same istio resources as above, just a different client config).

However, if you need to authenticate in-cluster workloads to each other, I would really suggest instead using Kubernetes service account, Istio mTLS and a principals: AuthorizationPolicy. I think the service account name is in the x-forwarded-client-cert header. Alternately, you could use something like Kubernetes projected service account tokens or GitLab CI JWTs. If any of these options are chosen, no changes to the Package CR need to be made, just deploy some AuthorizationPolicy resources from the Helm chart. I don't think Keycloak should be needed for two in-cluster workloads communicating.

Anyways, that's all TODO and can be done as a followup of this PR.

[bburky]

I did a bunch of testing today with @ldgriswold , and we realized that you don't get an aud audience claim by default, you need a mapper.

But if you're using a mapper anyway, you can customize the claim. If you pick the same audience as your authservice client, this lets your service accounts access authservice protected apps with no other configuration than defining a custom protocolMapper. This implements "grant=client_credentials auth to workload with automatic Istio JWT validation".

I updated the docs to include this and cleaned up some other code