[console-web] Alternative authentication method

[davgia]

Hi,

Is it possible to have a different authentication method for the web console? Why only STS? I usually have the ingress protected by oauth2-proxy so the ability to disable the authentication/login page would be appreciated.

Thanks in advance!

[Nightsee]

hi,
have you been able to connect using STS, I generated the token using the given command:
kubectl create token rustfs-operator -n rustfs-system --duration=24h

and when attempting to login, it does not work:
~# kubectl logs -n rustfs-system
2026-07-02T13:09:43.584549Z INFO operator::console::server: src/console/server.rs:63: Starting RustFS Operator Console port=9090
2026-07-02T13:09:43.585650Z INFO operator::console::server: src/console/server.rs:69: Kubernetes client initialized for STS authorization flow
2026-07-02T13:09:43.731356Z INFO operator::console::server: src/console/server.rs:154: Serving Console frontend static_dir=/app/console-web
2026-07-02T13:09:43.732524Z INFO operator::console::server: src/console/server.rs:122: Console server listening addr=0.0.0.0:9090
2026-07-02T13:09:43.732617Z INFO operator::console::server: src/console/server.rs:123: API endpoints:
2026-07-02T13:09:43.732749Z INFO operator::console::server: src/console/server.rs:124: - POST /api/v1/login
2026-07-02T13:09:43.732812Z INFO operator::console::server: src/console/server.rs:125: - GET /api/v1/tenants
2026-07-02T13:09:43.732909Z INFO operator::console::server: src/console/server.rs:126: - GET /healthz
2026-07-02T13:10:48.124787Z INFO operator::console::handlers::auth: src/console/handlers/auth.rs:35: Console login attempt
2026-07-02T13:10:48.135570Z WARN operator::console::handlers::auth: src/console/handlers/auth.rs:45: Console login Kubernetes API permission check failed error=ApiError: Unauthorized: Unauthorized (ErrorResponse { status: "Failur
e", message: "Unauthorized", reason: "Unauthorized", code: 401 })
2026-07-02T13:11:30.114852Z INFO operator::console::handlers::auth: src/console/handlers/auth.rs:35: Console login attempt
2026-07-02T13:11:30.122641Z WARN operator::console::handlers::auth: src/console/handlers/auth.rs:45: Console login Kubernetes API permission check failed error=ApiError: Unauthorized: Unauthorized (ErrorResponse { status: "Failur
e", message: "Unauthorized", reason: "Unauthorized", code: 401 })
2026-07-02T13:11:40.045498Z INFO operator::console::handlers::auth: src/console/handlers/auth.rs:35: Console login attempt
2026-07-02T13:11:40.055769Z WARN operator::console::handlers::auth: src/console/handlers/auth.rs:45: Console login Kubernetes API permission check failed error=ApiError: Unauthorized: Unauthorized (ErrorResponse { status: "Failur
e", message: "Unauthorized", reason: "Unauthorized", code: 401 })

[davgia]

Hi @Nightsee,

yes. I have generated the token and accessed the operator console. There are some error that pops with certain operations but it is working.

[Nightsee]

Hi @Nightsee,

yes. I have generated the token and accessed the operator console. There are some error that pops with certain operations but it is working.

using that very same command in the web console ?

[Nightsee]

in the ui I get this error:

Invalid or insufficient permissions

[GatewayJ]

Hi @Nightsee,

yes. I have generated the token and accessed the operator console. There are some error that pops with certain operations but it is working.

Could you please provide specific feedback? I will do my best to resolve the issue.

[GatewayJ]

in the ui I get this error:

Invalid or insufficient permissions

Are namespaces correct? Are they consistent with the actual deployment situation? The commands shown in the console web are just examples. We are currently considering how to optimize this.

[GatewayJ]

The current Operator Console authentication model is limited to Kubernetes ServiceAccount bearer tokens. The backend stores the validated Kubernetes token in the encrypted session cookie and uses that token as the Kubernetes identity for subsequent Console API requests.

So disabling the login page behind oauth2-proxy is not just a frontend change. We also need to define how an externally authenticated user maps to Kubernetes permissions, for example whether the Console should use its own ServiceAccount, Kubernetes impersonation, or another authorization model.

OAuth/OIDC and external-auth integration are on the roadmap, but this is not something we can safely complete in the short term. I will first improve the current token-based flow, including clearer documentation, better login guidance, and better error messages for invalid tokens or insufficient RBAC permissions. Then we can design the OAuth/OIDC support properly without accidentally weakening the Console authorization model.