docs(openshift): expand OpenShift guide with TLS, OIDC, ingress, and federated identity
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 8.7k
- Forks
- 1.3k
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 253
Description
Problem Statement
The current OpenShift documentation (docs/kubernetes/openshift.mdx) covers only a minimal plaintext HTTP + oc port-forward setup with TLS and PKI disabled. Users who follow the guide end up with no external access, no authentication, and no path forward beyond "refer to Ingress."
The generic ingress docs (docs/kubernetes/ingress.mdx) only cover Envoy Gateway, which cannot be installed on OpenShift because the Ingress Operator manages Gateway API CRDs and rejects the installation. There is no documented path for exposing the gateway on OpenShift.
The existing OpenShift page has:
- ✅ Namespace creation and SCC binding
- ✅ Basic Helm install command
- ❌ TLS (explicitly disabled)
- ❌ External access (only
oc port-forward) - ❌ Authentication (none)
- ❌ OIDC / Keycloak
- ❌ OpenShift Routes
- ❌ Gateway API / Istio
- ❌ Identity federation
Proposed Design
Expand docs/kubernetes/openshift.mdx into a multi-page section (docs/kubernetes/openshift/) with four sub-pages, following the same pattern as get-started/tutorials/:
1. Install (openshift/install.mdx)
TLS-enabled installation with SCC overrides. Replace the current plaintext-only path with pkiInitJob.enabled=true (the default). Document the SCC overrides (fsGroup=null, runAsUser=null) alongside TLS.
2. Gateway Connection (openshift/gateway-connection.mdx)
Three connection methods with trade-offs:
- Local access:
oc port-forwardfor evaluation - Routes: Why edge and passthrough break gRPC, reencrypt route with
backend-protocol=h2annotation as the working solution - Gateway API: Using the OpenShift-managed Istio GatewayClass with
GRPCRoute+DestinationRulefor TLS origination. Note that Envoy Gateway cannot be installed on OpenShift.
3. OIDC with Keycloak (openshift/oidc-keycloak.mdx)
- Creating a Keycloak realm, public client, and the required protocol mappers (
sub,aud,realm_access.roles) — Keycloak does not include these in access tokens for public clients by default - Helm values for OIDC with role-based access
- The
--oidc-issuerflag ongateway add— without it, the CLI defaults to the Cloudflare edge-auth flow which hangs indefinitely (#2057)
4. Identity Federation (openshift/identity-federation.mdx)
- Creating an
OAuthClientin OpenShift - Configuring the
openshift-v4IdP in Keycloak - ROSA HCP caveat:
baseUrlmust be the API server URL, not the OAuth route - Assigning realm roles to federated users after first login
All Keycloak commands provided in both kcadm.sh and REST API tabs.
Alternatives Considered
-
Update the existing single page: Adding all four topics to one page would make it too long (~600 lines) and hard to navigate. The multi-page section with a Cards index follows the established pattern (
get-started/tutorials/). -
Add OpenShift notes to existing generic pages (
ingress.mdx,access-control.mdx): Spreading OpenShift-specific content across multiple generic pages makes the OpenShift story hard to follow end-to-end. A dedicated section is easier to discover and maintain. -
Keep plaintext-only and link to generic docs: The current approach. Doesn't work because the generic ingress docs require Envoy Gateway (blocked on OpenShift) and the generic OIDC docs don't cover the Keycloak mappers required for public clients.
Agent Investigation
- Deployed and validated all four topics end-to-end on ROSA HCP 4.21 (OpenShift 4.21.3, Kubernetes 1.34.2)
- Tested both reencrypt Route and Gateway API (Istio) paths for external access
- Tested all
kcadm.shcommands in the Keycloak pod (--config /tmp/kcadm.configrequired for non-root containers) - Tested OIDC login with Keycloak and OpenShift identity federation (browser flow with "Login with OpenShift" button)
- Implementation PR: #2094
Related
- #2057 — CLI edge-auth defaults to Cloudflare
- #2060 / #2062 — certgen hardcodes namespace in SANs
- #2017 — TLS termination for Envoy Gateway ingress (Envoy-specific)
- #899 — restricted SCC support / Platform mode
- #2094 — implementation PR
- I've reviewed existing issues and the architecture docs
- This is a design proposal, not a "please build this" request
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review docs/kubernetes/openshift.mdx and the proposed docs/kubernetes/openshift/ section, comparing its structure with get-started/tutorials/. Check implementation PR #2094 and the documented OpenShift, Gateway API, Keycloak, and federation validation; the work is done when the four-page guide and its tested command examples are complete and navigable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- authentication, devops, documentation, networking
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 20/100