Identity providers and connection security

Identity integration

Built-in auth, LDAP, Google, and generic OIDC are supported. Provider settings apply at runtime without a restart. A blank LDAP group base DN disables group synchronization; when configured, memberships refresh on successful LDAP sign-in while local role mappings remain application-managed.

Connection security

Proxy TLS validation, SSRF and redirect controls, system proxy, and write-only upstream-secret handling are applied.

Inbound trust boundary

Define canonical HTTPS host, DNS, ingress class, TLS Secret, certificate chain, maximum body size, and long upload or download timeouts together for management UI and API plus package protocols. Validate HTTP-to-HTTPS redirection and proxy-header trust with the target ingress controller.

Identity-provider checklist

For every enabled provider, document owner, secret source, callback or redirect URI, issuer or LDAP endpoint, TLS trust, claim and group mapping, user-disable behavior, and emergency local-admin access.

• Successful sign-in and expected local or LDAP group mapping
• Controlled rejection for an invalid issuer, state, callback, bind, or certificate
• Removal of effective access for a user or group removed from the provider
• Observable failure and authorized break-glass procedure during provider outage

Outbound and proxy boundary

Handle package upstreams, OSV sources, LDAP or OIDC, and system-proxy destinations with separate allowlists and DNS or TLS policy. Full and incremental OSV synchronization use only objects below /osv-vulnerabilities/ on storage.googleapis.com:443; api.osv.dev and github.com are not required OSV runtime destinations. Repository upstream secrets are managed as write-only values; test target connectivity without disabling SSRF, redirect credential-scope, or TLS-validation controls.

Upstream certificate trust

Manage private-CA or self-signed upstream certificates through the product certificate-trust record and explicit repository scope, not through a global TLS bypass. Include certificate fingerprint, validity, covered repositories, approver, and revoke or rotation procedure in the evidence.

Secret and certificate operations

Application, database, S3, LDAP or OIDC, registry-pull, and TLS material must have separate secret lifecycles. Test rotation order, rollout impact, rollback, and old-credential revocation before production; never write values into values.yaml, logs, or evidence packs.

Connectivity acceptance criteria

For each internal and external connection, successful requests, DNS or TLS failures, timeouts, and authorization denials must be observable. Reconcile application logs, Outbound or Operation records, and ingress or provider evidence over the same time window.

Code and live-application validation — August 3, 2026

At current source commit 943c2c6, runtime LDAP, Google, and OIDC settings, JDBC sessions, system proxy, write-only secret behavior, and repository-proxy TLS, SSRF, and redirect controls were inspected. The targeted suite containing identity and proxy configuration passed 31 of 31 tests, and the TLS, SSRF, and redirect security suite passed 43 of 43. Using the built-in session on live kubaba.s3t.co, the Proxy, LDAP, Google, and OAuth/OIDC screens loaded read-only; the OIDC screen reported that no provider was configured. The endpoint served TLS 1.3 with a Let's Encrypt *.s3t.co certificate valid at the time. This evidence confirms code controls and the current inbound TLS and management surface; it did not exercise a real LDAP, Google, or OIDC sign-in, secret rotation, provider outage, or egress denial, so the page remains Evaluation guidance.