Auth Proxy Stack

What the Auth Proxy Stack is

The Auth Proxy template deploys an oauth2-proxy into a cluster you choose, from a single form. It gets a fixed address such as https://auth.<environment domain>. Stacks that support it, such as MLflow, offer Use existing Auth Proxy stack as their sign-in choice. People sign in once; the session cookie is set on the environment domain, so it covers every attached app.

When to use it

• You run, or plan to run, more than one internal tool in an environment and want one sign-in for all of them.
• Your company already has an identity provider (Okta, Entra ID, Keycloak, Auth0, GitHub or Google Workspace) and you want access decided there.
• You want to limit an app to a group, for example only ml-team for MLflow, without changing the app.

With a single app you can skip this stack: MLflow can run its own sign-in (New sign-in for this stack), with a host-only cookie.

The wizard estimates about 4 minutes. It needs a native (sgt-k8s) cluster and an environment with your own domain.

How it fits together

This is the whole path for a private MLflow behind an Auth Proxy. Notebooks, training jobs and CI skip the sign-in by using MLflow’s in-cluster address.

Browser
  |  https://mlflow.<domain>
  v
ingress-nginx  --- asks --->  Auth Proxy (auth.<domain>)
  |                                |
  |                                +--> your identity provider (sign-in)
  |                                |       |
  |                                +<------+  cookie on .<domain>
  v  allowed, with identity headers
MLflow UI

Notebooks / training jobs / CI
  |  in-cluster tracking URI (no sign-in)
  v
MLflow ---> Postgres (metadata)
       `--> S3 bucket in your account (artifacts)

Applications that sit behind the proxy receive the signed-in person’s identity as the headers X-Auth-Request-User, X-Auth-Request-Email and X-Auth-Request-Groups.

Deploy it

1. Open Applications → Templates and choose Auth Proxy.
2. Pick the environment and cluster, and the sign-in hostname (default auth).
3. Choose the provider and fill in its details, who may sign in, and session storage.
4. Deploy. Then copy Redirect URL to register from the Stack tab, or use the address the wizard showed, and register it with your provider. It is the sign-in address followed by /oauth2/callback.

Providers

Each Auth Proxy stack uses one provider.

Wizard fields

Session storage

Choose Redis when any of these apply:

• You need to cut off access immediately. With a cookie a signed-in person keeps access until the session expires.
• Your users belong to many groups. Groups are stored in the session; too many make the cookie larger than browsers allow and pages fail with a “header too large” error.
• You do not want the provider’s refresh token in the browser. Redis keeps it on the server; the browser holds only a random session ID.

Stay with the browser cookie for the fewest moving parts, for example with GitHub or Google sign-in, or OIDC without group rules.

Outputs

The Stack tab shows these once the stack is running.

Attach another stack to it

1. Deploy the Auth Proxy first, in the same environment as the stack you want to protect.
2. In the other stack’s wizard, set Sign-in to Use existing Auth Proxy stack. It is preselected when one exists. Pick the Auth Proxy stack.
3. Optionally set Allowed groups to restrict that app to some groups. Leave it empty to allow everyone the Auth Proxy lets in.

The attached app is exposed through ingress-nginx, which asks the Auth Proxy to approve each request. One sign-in then covers every attached app, because the cookie is set on .<domain>.

Machines and in-cluster services

• Services inside the cluster talk to an app by its in-cluster address and skip the proxy.
• With Custom OIDC, a bearer JWT issued by your provider for the API audience you set is accepted, so a machine can call through the public address without a browser sign-in.

Limits in this version

• You need the environment’s own domain. A shared Auth Proxy is refused on SeaGit’s shared domain, because its cookie would reach other customers’ apps.
• The hostname cannot be changed after the stack is created.
• One identity provider per Auth Proxy stack.
• The in-cluster address of an attached app has no sign-in, by design. Anything running in the cluster can use it.
• Custom OIDC must restrict sign-in by allowed email domains or allowed groups.

Related

• MLflow Stack, which can attach to an Auth Proxy
• Notebooks Stack and Redis Stack (for sessions)
• Domains and Certificates
• Private MLflow with single sign-on