docs: move the on-prem doc

omni.yaml

@@ -18,20 +18,19 @@ navigation:
             - "create-a-cluster.mdx"
             - "support-matrix.mdx"
 
+        - group: "Self Hosted"
+          folder: "omni/self-hosted"
+          pages:
+            - "overview.mdx"
+            - "omni-deployment-options.mdx"
+            - "deploy-omni-on-prem.mdx"
+            - "install-airgapped-omni.mdx"
+            - "deploy-image-factory-on-prem.mdx"
+            - "how-to-back-up-on-prem-omni-db.mdx"
+
         - group: "Infrastructure and Extensions"
           folder: "omni/infrastructure-and-extensions"
           pages:
-            - group: "Self Hosted"
-              pages:
-                - "self-hosted/overview"
-                - "self-hosted/omni-deployment-options"
-                - "self-hosted/deploy-omni-on-prem"
-                - "self-hosted/deploy-image-factory-on-prem"
-                - "self-hosted/configure-keycloak-for-omni"
-                - "self-hosted/how-to-back-up-on-prem-omni-db"
-                - "self-hosted/expose-omni-with-nginx-https"
-                - "self-hosted/upgrading-omni"
-            - "install-airgapped-omni.mdx"
             - "infrastructure-providers.mdx"
             - "writing-infrastructure-providers.mdx"
             - "machine-registration.mdx"
@@ -71,11 +70,13 @@ navigation:
             - "upgrading-clusters.mdx"
             - "omni-terraform.mdx"
             - "expose-an-http-service-from-a-cluster.mdx"
+            - "expose-omni-with-nginx-https.mdx"
             - "export-a-cluster-template-from-a-cluster-created-in-the-ui.mdx"
             - "etcd-backups.mdx"
             - "restore-etcd-of-a-cluster-managed-by-cluster-templates.mdx"
             - "using-audit-log.mdx"
             - "importing-talos-clusters.mdx"
+            - "upgrading-omni.mdx"
             - "wipe-a-machine.mdx"
             - "talos-config-overrides.mdx"
             - "override-ntp-servers.mdx"
@@ -97,6 +98,7 @@ navigation:
                 - "using-saml-with-omni/configure-oracle-cloud-for-omni"
             - "authentication-and-authorization.mdx"
             - "oidc-login-with-tailscale.mdx"
+            - "configure-keycloak-for-omni"
             - "how-to-manage-acls.mdx"
             - "omni-kms-disk-encryption.mdx"
             - "break-glass-emergency-access.mdx"

public/docs.json

@@ -2168,23 +2168,20 @@
               "omni/getting-started/support-matrix"
             ]
           },
+          {
+            "group": "Self Hosted",
+            "pages": [
+              "omni/self-hosted/overview",
+              "omni/self-hosted/omni-deployment-options",
+              "omni/self-hosted/deploy-omni-on-prem",
+              "omni/self-hosted/install-airgapped-omni",
+              "omni/self-hosted/deploy-image-factory-on-prem",
+              "omni/self-hosted/how-to-back-up-on-prem-omni-db"
+            ]
+          },
           {
             "group": "Infrastructure and Extensions",
             "pages": [
-              {
-                "group": "Self Hosted",
-                "pages": [
-                  "omni/infrastructure-and-extensions/self-hosted/overview",
-                  "omni/infrastructure-and-extensions/self-hosted/omni-deployment-options",
-                  "omni/infrastructure-and-extensions/self-hosted/deploy-omni-on-prem",
-                  "omni/infrastructure-and-extensions/self-hosted/deploy-image-factory-on-prem",
-                  "omni/infrastructure-and-extensions/self-hosted/configure-keycloak-for-omni",
-                  "omni/infrastructure-and-extensions/self-hosted/how-to-back-up-on-prem-omni-db",
-                  "omni/infrastructure-and-extensions/self-hosted/expose-omni-with-nginx-https",
-                  "omni/infrastructure-and-extensions/self-hosted/upgrading-omni"
-                ]
-              },
-              "omni/infrastructure-and-extensions/install-airgapped-omni",
               "omni/infrastructure-and-extensions/infrastructure-providers",
               "omni/infrastructure-and-extensions/writing-infrastructure-providers",
               "omni/infrastructure-and-extensions/machine-registration",
@@ -2232,11 +2229,13 @@
               "omni/cluster-management/upgrading-clusters",
               "omni/cluster-management/omni-terraform",
               "omni/cluster-management/expose-an-http-service-from-a-cluster",
+              "omni/cluster-management/expose-omni-with-nginx-https",
               "omni/cluster-management/export-a-cluster-template-from-a-cluster-created-in-the-ui",
               "omni/cluster-management/etcd-backups",
               "omni/cluster-management/restore-etcd-of-a-cluster-managed-by-cluster-templates",
               "omni/cluster-management/using-audit-log",
               "omni/cluster-management/importing-talos-clusters",
+              "omni/cluster-management/upgrading-omni",
               "omni/cluster-management/wipe-a-machine",
               "omni/cluster-management/talos-config-overrides",
               "omni/cluster-management/override-ntp-servers",
@@ -2262,6 +2261,7 @@
               },
               "omni/security-and-authentication/authentication-and-authorization",
               "omni/security-and-authentication/oidc-login-with-tailscale",
+              "omni/security-and-authentication/configure-keycloak-for-omni",
               "omni/security-and-authentication/how-to-manage-acls",
               "omni/security-and-authentication/omni-kms-disk-encryption",
               "omni/security-and-authentication/break-glass-emergency-access",

public/kubernetes-guides/advanced-guides/deploy-traefik.mdx

@@ -88,7 +88,7 @@ EOF
 
 ```
 
-## Step 4: Deploy a Sample Application
+## Step 4: Deploy an application
 
 Deploy a simple test application called whoami.
 
@@ -158,7 +158,7 @@ EOF
 
 ```
 
-## Step 6: Test the Setup
+## Step 6: Test the setup
 
 Finally, verify that Traefik is routing traffic correctly.
 

public/kubernetes-guides/advanced-guides/device-plugins.mdx

@@ -7,7 +7,7 @@ description: "In this guide you will learn how to expose host devices to the Kub
 This guide will show you how to deploy a device plugin to your Talos cluster.
 In this guide, we will use [Kubernetes Generic Device Plugin](https://github.com/squat/generic-device-plugin), but there are other implementations available.
 
-## Deploying the Device Plugin
+## Deploying the device plugin
 
 The Kubernetes Generic Device Plugin is a DaemonSet that runs on each node in the cluster, exposing the devices to the pods.
 The device plugin is configured with a [list of devices to expose](https://github.com/squat/generic-device-plugin#overview), e.g.
@@ -104,7 +104,7 @@ Allocated resources:
   squat.ai/tun       0            0
 ```
 
-## Deploying a Pod with the Device
+## Deploy a pod with the device
 
 Now that the device plugin is deployed, you can deploy a pod that requests the device.
 The request for the device is specified as a [resource](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) in the pod spec.

public/kubernetes-guides/advanced-guides/dynamic-resource-allocation.mdx

@@ -34,7 +34,7 @@ cluster:
 
 You should have at least one node in the cluster with NVIDIA hardware and configured via the <a href={`../../talos/${version}/configure-your-talos-cluster/hardware-and-drivers/nvidia-gpu-proprietary`}>NVIDIA system extension and patch</a>
 
-## 1. Deploy the NVIDIA DRA plugin via helm
+## 1. Deploy the NVIDIA DRA plugin via Helm
 
 Use helm to install the DRA plugin.
 

public/kubernetes-guides/advanced-guides/gcp-workload-identity.mdx

@@ -6,7 +6,7 @@ description: "Guide on how to configure Google Cloud Workload Identity Federatio
 This guide provides a step-by-step walkthrough for configuring Google Cloud Workload Identity Federation on a Talos Kubernetes cluster. 
 It covers setting up the necessary GCP infrastructure (buckets, pools, providers), patching the Talos API server with RSA keys for OIDC compatibility, and binding Kubernetes Service Accounts to Google Service Accounts for secure authentication.
 
-## Environment Setup
+## Environment setup
 
 We'll make use of the following environment variables throughout the setup.
 Edit the variables below with your correct information.
@@ -19,7 +19,7 @@ export PROVIDER_NAME="WorkloadIdentityProvider"
 export REGION="us-east1"
 ```
 
-## GCP Infrastructure
+## GCP infrastructure
 
 ### Create the OIDC Storage Bucket
 
@@ -46,7 +46,7 @@ gcloud iam workload-identity-pools create ${POOL_NAME} \
   --display-name="Talos Workload Identity Pool"
 ```
 
-### Create the OIDC Provider
+### Create the OIDC provider
 
 Create an OIDC provider that trusts tokens from the specified issuer, enabling secure external authentication to Google Cloud.
 
@@ -59,9 +59,9 @@ gcloud iam workload-identity-pools providers create-oidc ${PROVIDER_NAME} \
   --attribute-mapping="google.subject=assertion.sub,attribute.sub=assertion.sub"
 ```
 
-## Talos Configuration
+## Talos configuration
 
-### RSA Key
+### RSA key
 
 Now we will patch the Talos Kubernetes cluster api-server to use this OIDC provider as api-audiences alongside the default API server audience. 
 Talos by default generates ECDSA keys for Kubernetes service account verification which don’t work with Google’s IAM Workload Identity Pool OIDC provider. 
@@ -71,7 +71,7 @@ Instead, we need to generate an RSA key and replace the default service account
 RSA_KEY_ENCODED=$(openssl genrsa 4096 2> /dev/null | base64 -w 0)
 ```
 
-### Retrieve OIDC Provider URL
+### Retrieve OIDC provider URL
 
 Retrieve the URL of the OIDC provider for configuring external authentication.
 
@@ -102,7 +102,7 @@ cluster:
 EOF
 ```
 
-### Apply OIDC Patch to Control Plane Node
+### Apply OIDC patch to control plane node
 
 Retrieve a Control Plane node’s IP and apply the OIDC patch to configure the cluster for Workload Identity authentication
 
@@ -112,7 +112,7 @@ CONTROL_PLANE_NODE_ADDRESS=$(kubectl --kubeconfig kubeconfig get nodes --output
 talosctl patch machineconfig --talosconfig talosconfig --patch @oidc-patch.yaml --nodes ${CONTROL_PLANE_NODE_ADDRESS}
 ```
 
-### Retrieve Kubernetes OIDC Configuration
+### Retrieve Kubernetes OIDC configuration
 
 Download the cluster’s keys.json and discovery.json files, which contain the OIDC public keys and discovery metadata needed for external authentication.
 
@@ -133,7 +133,7 @@ gcloud storage cp discovery.json gs://${BUCKET_NAME}/.well-known/openid-configur
 curl https://storage.googleapis.com/$BUCKET_NAME/.well-known/openid-configuration
 ```
 
-## Identity Binding & Permissions
+## Identity binding & permissions
 
 ### Create the Google Service Account (GSA)
 
@@ -144,15 +144,15 @@ GSA_NAME="talos-workload-sa"
 gcloud iam service-accounts create ${GSA_NAME} --project=${PROJECT_ID}
 ```
 
-### Get the Workload Identity Pool Name
+### Get the Workload Identity Pool name
 
 Retrieve the full resource name of the Workload Identity Pool for configuring identity bindings.
 
 ```bash
 WORKLOAD_IDENTITY_POOL_URL=$(gcloud iam workload-identity-pools list --location="global" --filter="name:${POOL_NAME}" --format json | jq -r '.[].name')
 ```
 
-### Grant Permissions to the GSA
+### Grant permissions to the GSA
 
 Assign the necessary roles to the Google Service Account, including access to project resources and the ability to be impersonated via Workload Identity.
 
@@ -167,7 +167,7 @@ gcloud iam service-accounts add-iam-policy-binding "${GSA_NAME}@${PROJECT_ID}.ia
 ```
 <Note> Ensure the member string matches your specific Kubernetes configuration. The format is `system:serviceaccount:<NAMESPACE>:<KSA_NAME>`. In this example, we use the default namespace and the workload-identity service account.</Note>
 
-### Generate the Workload Identity Config File
+### Generate the Workload Identity configuration file
 
 Create a local configuration file that maps the Kubernetes service account to the Google Service Account for authentication.
 
@@ -178,25 +178,25 @@ gcloud iam workload-identity-pools create-cred-config \
     --credential-source-file="/var/run/secrets/tokens/gcp-ksa/token" \
     --output-file=sts-creds.json
 ```
-## Deployment & Verification
+## Deployment & Vverification
 
-### Deploy Credential ConfigMap
+### Deploy credential configMap
 
 Create a ConfigMap to store the credential configuration file, enabling the Pod's Google SDK to perform the token exchange.
 
 ```bash
 kubectl --kubeconfig kubeconfig create configmap workload-identity-config --from-file=google-application-credentials.json=sts-creds.json -n default
 ```
 
-### Create a Kubernetes Service Account
+### Create a Kubernetes service account
 
 Create the Kubernetes Service Account that will be bound to the Google Service Account to authorize the workload.
 
 ```bash
 kubectl --kubeconfig kubeconfig create serviceaccount workload-identity --namespace default
 ```
 
-### Deploy Test Pod
+### Deploy test pod
 
 Deploy a Pod that projects the Service Account token and credential configuration to verify the identity federation.
 
@@ -244,7 +244,7 @@ spec:
 EOF
 ```
 
-### Verify Access
+### Verify access
 
 Execute a command inside the running Pod to list the storage bucket contents, confirming that the Workload Identity authentication is functioning correctly.
 

public/kubernetes-guides/advanced-guides/inlinemanifests.mdx

@@ -50,7 +50,7 @@ cluster:
     - "https://gist.githubusercontent.com/user/gist-id/raw/manifest.yaml"
 ```
 
-## Resource Ordering Considerations
+## Resource ordering considerations
 
 Talos automatically sorts all manifests, including `inlineManifests`, `extraManifests`, and built-in manifests (such as the kubelet bootstrap token and CoreDNS), before applying them in the following order:
 
@@ -104,7 +104,7 @@ You can skip this step if you've already done it:
     kubectl get pods -n flux-system -w
     ```
 
-## Omni Patches
+## Omni patches
 
 You can also apply `inlineManifests` or `extraManifests` patches to Talos clusters managed by Omni.
 
@@ -122,7 +122,7 @@ Here’s a quick overview of the key differences between `inlineManifests` and `
 | Benefits               | No external dependencies                       | Centrally managed                                            |
 | Disadvantages          | Difficult to maintain and format embedded YAML | Requires external HTTP server                                |
 
-## How Talos Handles Manifest Resources
+## How Talos handles manifest resources
 
 Talos reconciles manifests on every boot, on every failure to apply, and on every change to the manifests in the machine config.
 When processing your `inlineManifests` and `extraManifests`, Talos follows a conservative, additive-only approach.

public/kubernetes-guides/advanced-guides/kubeprism.mdx

@@ -13,7 +13,7 @@ If the external cluster endpoint is unavailable (due to misconfiguration, networ
 
 KubePrism solves this problem by enabling an in-cluster highly-available controlplane endpoint on every node in the cluster.
 
-## Video Walkthrough
+## Video walkthrough
 
 To see a live demo of this writeup, see the video below:
 

public/kubernetes-guides/advanced-guides/kuberay.mdx

@@ -8,7 +8,7 @@ import { version } from '/snippets/custom-variables.mdx';
 [Ray](https://www.ray.io/) is a project for running machine learning jobs in a cluster of machines. [KubeRay](https://github.com/ray-project/kuberay) is an operator for installing Ray on top of Kubernetes.
 For up-to-date installation guide check with the [upstream Ray documentation](https://docs.ray.io/en/latest/cluster/kubernetes/getting-started/kuberay-operator-installation.html).
 
-## Install Ray operator with helm
+## Install Ray operator with Helm
 
 Create a Kubernetes cluster with [`talosctl`](../../omni/getting-started/how-to-install-talosctl) or via [Omni](../../omni/overview/what-is-omni).
 

public/kubernetes-guides/advanced-guides/node-labels.mdx

@@ -49,7 +49,7 @@ After applying the machine config and rebooting the node, verify the labels with
 kubectl describe node <node-name>
 ```
 
-### Role Labels
+### Role labels
 
 To assign Kubernetes role labels such as:
 
@@ -65,7 +65,7 @@ kubectl label node <node-name> node-role.kubernetes.io/worker=""
 
 Alternatively, you can use the [Talos Cloud Controller Manager](https://github.com/siderolabs/talos-cloud-controller-manager/blob/main/docs/config.md) or your own controller to translate custom domain labels into the conventional `node-role.kubernetes.io/*` form if required.
 
-## Node Taints
+## Node taints
 
 Kubernetes taints let you prevent workloads from being scheduled on a node unless they have matching tolerations. You can learn more in the official [Taints and Tolerations documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).
 
@@ -76,7 +76,7 @@ Attempting to do so results in errors such as: `<node-name> is not allowed to mo
 
 This behaviour is expected and required for Kubernetes hardening.
 
-### Apply Taints
+### Apply taints
 
 Talos supports setting initial taints only during first node registration, using the kubelet's `registerWithTaints` configuration.
 
@@ -110,7 +110,7 @@ Apply this patch to your worker node’s configuration file.
 
 The taint will be applied once, during the node’s initial registration with the Kubernetes API server. After the node has joined the cluster, updating this field will no longer have any effect.
 
-### Modify Taints After Bootstrap
+### Modify taints after bootstrap
 
 After a node has joined the cluster, taints must be managed using a cluster-admin identity: