Support customizing kubernetes objects created by managed outposts

[ruifung]

Is your feature request related to a problem? Please describe.
On my cluster, I have both local, on premises nodes as well as nodes running in cloud instances. The outpost deployments generated by the kubernetes integration does not support specifying a nodeSelector or affinity options.

Node placement is more of a concern when dealing with outposts that may need to be exposed outside the cluster, such as RADIUS or LDAP outposts, and where you ideally want their externalTrafficPolicy to be Local to preserve the requesting source IPs.

It might also be a concern if you're literally using the proxy outpost to... proxy... instead of using an external reverse proxy to forward-auth.

Describe the solution you'd like
Either allowing a nodeSelector or affinity to be specified as part of the outpost configuration.

Describe alternatives you've considered
Supporting a more generic jsonpatch/strategicMergePath approach to patching it.

Additional context

[BeryJu]

I think the best option would be to allow for JSON patching of the objects created, as if we start going down the route of supporting more and more attributes via the Outpost config, we'll end up with a lot of boilerplate over time. Another idea would be to use something like helm/etc to install the outpost and have the worker do that, and allow for specifying a values override.

It could be done with a library like https://python-json-patch.readthedocs.io/en/latest/index.html to allow for JSON patching of the objects before they are reconciled, however this might also introduce some potential issues as some fields might need to be compared differently by authentik to see if an object should be updated or re-created

[ruifung]

I mean, that would indeed be the preferable option, since it would be flexible enough to handle k8s changes in the future. I imagine jsonpatch would be the preferable given the way outpost configuration is handled right now compared to something like a strategicMergePatch.

Or perhaps rather then helm, the manifests could be rendered using kustomize? Since it seems to natively support jsonpatch already. (And it's actually built into kubectl nowadays.)

Though I'm unsure what you mean by comparing fields, unless you're comparing the fields before generating the k8s manifests.
Granted, there's a bunch of fields that can't be updated after it's been created and may not even originate from authentik. In that case, why not adopt the approach that fluxcd2 does with it's "force" function? If it fails to update, recreate it.

[BeryJu]

Both helm and kustomize would be somewhat annoying to integrate as they’re go and most of authentik is python

For the comparison, authentik checks some hard coded fields to know when to update an object, so any custom patches might not be compared and might not cause an update.

I’m looking for the simplest solution for this for the main reason that I don’t really want to build an entire kubernetes IaC platform for something like this, so I’ll probably go with json patches and keep that as a side effect that changes to those patches might not always trigger a reconciliation

[ruifung]

If you're talking about the outpost configuration fields..
Perhaps just having a blanket recreate-on-patch-change might be an acceptable tradeoff?
Wouldn't complicate the update logic, and wouldn't potentially leave the running outpost configuration inconsistent with the expected configuration.