authentik Kubernetes Operator

[BeryJu]

Implement a kubernetes "operator" in the authentik worker

• Create a CRD for blueprints
• Leader election in the worker container(s)
• Leader worker will watch for API changes on blueprint objects
• Blueprint contents will be saved in blueprint instance objects with internal storage
• Kubernetes managed blueprins should show up as such in the webui
• Invalid blueprints' status will be written to the blueprint CRD
  • Maybe have a validation webhook?
  • We don't want to have the entire blueprint schema in the CRD, as that schema changes almost every authentik version and would be painful to upgrade

related to https://github.com/goauthentik/helm/issues/127 related to https://github.com/goauthentik/helm/pull/146 related to https://github.com/goauthentik/authentik/issues/4558 related to https://github.com/goauthentik/authentik/issues/4119

[genofire]

related https://github.com/goauthentik/authentik/issues/5300 (declarative blueprints)

[DreamingRaven]

I hope you don't mind me putting in my two cents:

We don't want to have the entire blueprint schema in the CRD, as that schema changes almost every authentik version and would be painful to upgrade

https://gitlab.com/GeorgeRaven/authentik-manager/-/blob/master/operator/api/v1alpha1/akblueprint_types.go#L34 I agree I use json.RawSchema for highly varying fields but I try to keep at-least the structure of a blueprint concrete.

It would be fantastic to have a webhook to validate CRDs against the current api of authentik that would make things a lot easier in particular for a CRD that may not have the validation for every specific field! This would also be super helpful just in general when writing blueprints someone could feasibly spin up an instance and validate as they go.

I am not certain how this will translate to python however, possibly marshmallow for handling a complex CRD schema? (not sure what you use internally to validate blueprints)

[danielloader]

On the note of an operator, some sort of capacity to define a client either providing the secret externally or exporting the secret back out to a kubernetes secret option by nameRef would be extremely handy for automating deployment of clients and the applications that use them.

Alternatively a crossplane provider similar to https://github.com/crossplane-contrib/provider-keycloak

[MacroPower]

@danielloader I made a Crossplane provider for Authentik using upjet (code generated from the Terraform provider) and have been using it for a few months: https://github.com/MacroPower/provider-authentik

Example provider config: https://github.com/MacroPower/homelab/blob/main/applications/base/crossplane-packages/authentik.yaml

I'm still learning about Compositions and am working on making some examples here: https://github.com/MacroPower/homelab/tree/main/applications/base/authentik/config

It's pretty nice because you can create a Composition that has just a couple of inputs and use it to create an Application and all its dependencies, plus you can reference anything in the Composition environment.

Main issue I've been dealing with is the unpredictable naming that Authentik uses, e.g. GUIDs for some things, integer primary keys for some things, slugs for others. Makes it difficult to reference things like the embedded outpost. I'm sure there is a way to do it but I'm still somewhat new to Compositions.