Enable Dataverse to be used in (Kubernetes) service-to-service (Admin) API interactions

Overview of the Suggestion

To enable service-to-service communication in K8s clusters, it would be perfect to reuse the service accounts an K8s operator can define for some deployment/pod/... This would enable a whole lot of interactions in such systems.

What kind of user is the suggestion intended for?
API User, Superuser, Sysadmin

What inspired this idea?
How can we make Admin API access happen for some K8s Job/Operator or other Microservice?

1. Without the need to create some superuser first
2. Without somehow extracting and storing the API token for this user (so the "client" can use it)
3. Dropping the necessity for "unblock-key"?

What existing behavior do you want changed?

1. Need an auth provider implementation that uses the K8s TokenReview API to verify the authenticity and then uses the K8s ServiceAccount API to extract annotations/labels for group/role mapping. These are 2 HTTP calls, so fairly trivial, no external dependency necessary.
2. Need to map the service accounts to be superusers and maybe groups etc.
3. Need to hide the system-internal provider from the UI
4. Refactor the Admin API to be usable using priviliged tokens (add new policy to allow access with superuser-enabled service account token)
5. Need to be able to inject trust by replacing Payara's JKS at runtime using trust-manager, which uses the K8s-injected kube-root-ca.crt ConfigMap to distribute HTTPS trust for the K8s API.
   (domain.xml: <jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.p12</jvm-options>)

Any brand new behavior do you want to add to Dataverse?
Not really brand new, but somewhat new, as we'd introduce support for K8s APIs into the application's codebase.

Any open or closed issues related to this suggestion?

• #11639
• #7659
• #9969

Are you thinking about creating a pull request for this issue?
I most certainly will - it would make my job a hell lot easier!

Start by reviewing related issues #11639, #7659, and #9969, then trace the Admin API authentication and authorization paths. Investigate Kubernetes TokenReview and ServiceAccount APIs and the Payara trust-store setting in domain.xml. Done means service-account tokens can be verified and mapped to roles or groups, privileged Admin API access is supported, and the internal provider is hidden from the UI.