Static authentication token

[john9x]

It is possible to set up static authentication token for all users or somehow prefill login form with static token value? I have hawtio installation behind identity proxy and I don't want hawtio login for authenticated users

[phantomjinx]

Hey @john9x

I'd like to understand a little more about your use-case, please. The token value required to be filled is not just for the login authentication but is retained and attached to each fetch request as the Authorization for accessing the kubernetes API. In a secure cluster, no requests to any of the jolokia apps will be successful without the token.

So is your cluster not secured or does it have a single user from which to extract a token credential?

[john9x]

I have clusters with deployed Java apps and I have developers that want to have access to JMX, the developers have no access to k8s, just to identity proxy with OAuth (Pomerium) -> Hawtio Online UI.

does it have a single user from which to extract a token credential?

Yes. I have created special single user, obtain token and use it to login but it is not comfortable.

I have made a crutch - proxy always replace Authentication header with Bearer <my static token> and user can login with every symbol as token but it works not so good, sometimes it requires pages reload.

[grgrzybek]

May I ask for more details about this identity proxy? Is it running within k8s or outside?

[john9x]

@grgrzybek identity proxy is running outside, in a separate cluster. hawtio exposed using internal ingress.

[grgrzybek]

Thanks for clarification. Initially I thought "identity" is some kind of "1:1" for proxy:backend.
Words change meaning quite often recently...

[john9x]

@grgrzybek My bad :) "identity proxy" - wrong terminology. identity-aware proxy

[grgrzybek]

https://www.pomerium.com/docs/get-started/fundamentals/core/self-hosted-pomerium#configure-an-identity-provider shows these OAuth2:

Apple
Auth0
Azure AD
Cognito
GitHub
GitLab
Google
Okta OneLogin
Ping

which one do you use? just to get a view on your architecture.
I'm asking because it is not an obligation for such IdP to issue actual JWT tokens.

We usually use Keycloak, which is mentioned under https://www.pomerium.com/docs/integrations/user-identity/oidc

[john9x]

which one do you use?

Google

[grgrzybek]

So summarizing, you have a Pomerium config similar to:

idp_provider: google
authenticate_service_url: <some url?>

routes:
  - from: <your internal url>
    to: <url of Hawtio Online>

?

[john9x]

@grgrzybek yes, something like

[phantomjinx]

If we were to configure an alternative to Form login, eg. Public.
So

• An oauth-provider is integrated into the cluster (user ids mapped to roles), The likes of AWS and GKE already have this;
• Hawtio utilises oauth2-proxy to authenticate against that same oauth-provider
• Hawtio simply acquires the bearer token from the oauth-provider and presents that for authentication to the cluster

Would that allow you to configure Pomerium as the oauth-provider of your cluster then users login once and can access the cluster using SSO?

Alternatively, if you didn't want to integrate Pomerium into the Hawtio cluster then we could setup oauth2-proxy as an impersonator.

• users authenticate against Pomerium via the oauth2-proxy.
• If successful, the users are given the oauth-2-proxy's own token which is configured to allow impersonation.
• All calls to Hawtio's cluster are executed with the oauth2-proxy token.

We could provide the oauth2-proxy sidecar with enough config options to allow either of these approaches, I think.

[john9x]

Would that allow you to configure Pomerium as the oauth-provider of your cluster then users login once and can access the cluster using SSO?

I this this is not an option.

setup oauth2-proxy as an impersonator

hmmm. Do you mean ouath2-proxy will be an identity provider for pomerium but for oauth2-proxy IdP will be Google ?

[john9x]

Is it possible to support JWT verification in hawtio side ?

[phantomjinx]

Hopefully this should make clear the impersonator architecture:

The roles here are actually the other way around. Pomerium remains the master identity provider (IdP) for Hawtio, and Google the credential source for Pomerium.

When we talk about using OAuth2-Proxy as an impersonator, we are solving a specific problem:

"How do we let a user log in via Pomerium if the underlying Kubernetes cluster doesn't know or trust Pomerium?"

Here is how the Impersonation flow would work:

1. The Login (SSO is preserved)
   You do not log in twice. You log in once via Pomerium (which might be backed by Google, Okta, etc.).

   • Pomerium says: "Yes, this is Alice."
   • Pomerium hands Alice's identity over to OAuth2-Proxy (running as a sidecar next to Hawtio).

2. The Problem
   At this point, Alice wants to see her Pods. Hawtio needs to ask the Kubernetes API for that data. Usually, Hawtio would pass Alice's Pomerium token to the cluster. But if this is an AWS, Google, or Vanilla cluster that hasn't been explicitly configured to trust Pomerium, the cluster will say: "I don't know what a Pomerium token is. Access Denied."

3. The Solution: Impersonation
   This is where OAuth2-Proxy acts as the Impersonator.
   Instead of passing Alice's untrusted token to the cluster, OAuth2-Proxy uses its own highly trusted Kubernetes Service Account token. This Service Account has a special permission in the cluster called "impersonate".

The flow looks like this:

• Hawtio (via OAuth2-Proxy) talks to the Kubernetes API.
• It presents the OAuth2-Proxy Service Account Token (which the cluster trusts completely).
• It attaches a special header to the request: Impersonate-User: alice@company.com.
• The Kubernetes API looks at the request and says: "I trust OAuth2-Proxy, and since it has impersonation rights, I will execute this request as if Alice herself were running it."

This will mean that instead of presenting your static authentication token to your users for them to paste into the Form login page manually, you in effect automate this process through the oauth2-proxy.

The oauth2-proxy is flexible enough that it can be configured in a number of ways depending on the setup of the cluster its installed on:

• Mode 1: Pass-Through (OIDC Native)
• Mode 2: Impersonation (The "Bridge")

JWT Verification

In this architecture, the JWT is validated at two distinct levels before Hawtio does any processing:

• Gate 1: The Proxy (Pomerium/OAuth2-Proxy): The proxy's entire job is to verify the JWT. If the token is expired, has an invalid signature, or comes from an untrusted issuer, the proxy rejects the request immediately. It never even forwards the traffic to Hawtio.
• Gate 2: The Kubernetes API Server: When Hawtio takes that token and tries to list pods or read logs, it sends the token to the Kubernetes API. The API server then performs its own cryptographic verification of the JWT. If the token is invalid, the API returns a 401 Unauthorized to Hawtio.

[john9x]

@phantomjinx now I see what you mean, thanks for the explanation! I think this should work