Using the MLflow Python SDK with Authentication and RBAC
On Alauda AI the MLflow Tracking Server runs behind single sign-on and multi-tenancy: an OAuth proxy authenticates every caller, and the server records each run under the calling user and authorizes it against Kubernetes RBAC. This guide drives the stock MLflow Python SDK through that OAuth proxy with your own identity, browser-free, using the OAuth2 authorization code flow (with PKCE) scripted against the platform login — no password grant, and never the MLflow container port.
There are two browser-free ways to present your identity; pick one:
- Bearer token (recommended). Obtain a Dex id token from the CLI or Python and pass it as
MLFLOW_TRACKING_TOKEN; renew it with the refresh token. Needs one platform setting (below). - Session cookie (no platform changes). Drive the proxy's own login to obtain its
_oauth2_proxycookie and attach it to requests. Works on any install as-is (below).
TOC
How authentication worksPrerequisitesPlatform setup for the token method (administrator, one-time)Get a token from the command line (browser-free)Python helperShell equivalent (curl + openssl, no Python dependencies)Connect the SDKSelecting a workspaceRegistering modelsAlternative: session cookie (no platform changes)TroubleshootingHow authentication works
Two layers sit in front of your runs:
- The OAuth proxy (
oauth2-proxy) authenticates the request — either a Dex id token sent asAuthorization: Bearer …(token method) or its_oauth2_proxysession cookie (cookie method). - The MLflow server's
kubernetes-authplugin reads your identity from that credential, records it as the run owner, and authorizes it against your Kubernetes permissions in the workspace.
The client always goes through the OAuth proxy — never connect to the MLflow container port directly.
Prerequisites
mlflow3.10 or later (pip install "mlflow>=3.10"). Workspace selection (mlflow.set_workspace) is a 3.10+ feature. The Python token helper also usesrequestsandcryptography.- A platform username and password that can access the target workspace (see Workspaces and access control). This is an ordinary platform login — not a Kubernetes ServiceAccount — and a normal user account works. For shared or automated use (pipelines, headless jobs), prefer a dedicated, non-personal account over an individual's login, since the credentials/token are stored in a
Secretand every run is recorded under whoever you authenticate as. - The platform's OAuth client id and secret — the client the MLflow proxy uses (from your administrator). On Alauda this is the platform auth client, e.g.
alauda-auth; its secret lives in a KubernetesSecret(e.g.cpaas-oidc-secret).
Platform setup for the token method (administrator, one-time)
The bearer-token method needs the MLflow OAuth proxy to accept Dex id tokens. Add --skip-jwt-bearer-tokens=true to the MLflow plugin — this is the MLflow proxy on the workload cluster, not the platform's global auth server:
No Dex or global-auth change is required: the login below uses the authorization_code grant the platform client already allows. The cookie method needs no setting at all — skip this section if you use it.
Get a token from the command line (browser-free)
The platform login is an SSO page, but its API supports the standard OAuth authorization code flow with PKCE, so you can complete it from a script — no browser redirect. The password is RSA-encrypted with the login service's public key (/dex/pubkey), exactly as the login page does it, then exchanged for an id token (and a refresh token for headless renewal).
Python helper
Shell equivalent (curl + openssl, no Python dependencies)
Connect the SDK
The run appears under Alauda AI → Tools → MLFlow, owned by the user you authenticated as. (Verified end-to-end on a secured install: the run owner is the token's user identity.)
Use the in-cluster Service URL http://mlflow-tracking-server.kubeflow:5000 when the client runs inside the cluster (pipeline components, Workbench notebooks). From outside the cluster, point at the platform route https://<platform>/clusters/<cluster>/mlflow instead — both reach the same OAuth proxy (set MLFLOW_TRACKING_INSECURE_TLS=true if the platform certificate is not trusted by your machine).
For shared or headless use, prefer a dedicated, non-personal account (an ordinary platform login, not a Kubernetes ServiceAccount) and keep its credentials and the client secret in a Kubernetes Secret, never in code. Always .strip() the token (a trailing newline produces Invalid … character(s) in header value: 'Bearer …\n'). id tokens expire (24 h by default); for long-running jobs renew with refresh(tok["refresh_token"]) instead of logging in again.
Selecting a workspace
Runs are recorded in the workspace you select; if you select none, the server's default workspace is used. Any of these set it (the SDK turns them into the X-MLFLOW-WORKSPACE header):
mlflow.set_workspace("team-a")in code,- the
MLFLOW_WORKSPACE=team-aenvironment variable.
You can only use a workspace your account has access to; see Workspaces and access control.
Registering models
The model registry is workspace-scoped and authorized the same way, so the usual SDK calls work once connected:
Promote the registered version to Staging or Production from the MLflow UI.
Alternative: session cookie (no platform changes)
If you cannot enable --skip-jwt-bearer-tokens, drive the proxy's own login flow to obtain its _oauth2_proxy cookie and attach it to requests — this works on any install unchanged. The proxy starts the OAuth flow for you (its own PKCE and redirect_uri); you just replay that through the same scripted login and hand the code back to the proxy callback:
Then attach the cookie with a header provider (the cookie carries your identity — no token, no platform setting):
From inside the cluster, point at the in-cluster Service URL http://mlflow-tracking-server.kubeflow:5000 instead (no TLS issues). On the external https://<platform>/… route the platform certificate is self-signed, so set MLFLOW_TRACKING_INSECURE_TLS=true (or point REQUESTS_CA_BUNDLE at the platform CA).
You can also copy the _oauth2_proxy cookie from a browser session (DevTools → Application/Storage → Cookies). The session cookie expires — re-mint it when calls start returning a login redirect.