Rebase updated docs structure

docs/deployment/distribution-support.md → docs/reference/UDS Core/distribution-support.md

@@ -1,7 +1,5 @@
 ---
 title: Distribution Support
-type: docs
-weight: 1
 ---
 
 UDS Core is a versatile software baseline designed to operate effectively across a variety of Kubernetes distributions. While it is not specifically tailored to any single Kubernetes distribution, it is compatible with multiple environments. This documentation provides an overview of UDS Core's compatibility with different distributions and the level of support provided.
@@ -12,8 +10,8 @@ UDS Core is a versatile software baseline designed to operate effectively across
 
 - **Compatible:** Kubernetes distributions listed under this category may not have undergone extensive testing in UDS Core's CI environments. While UDS Core may be compatible on these distributions, users should exercise caution and be prepared for potential compatibility issues or limitations.
 
-| Distribution        | Category               | Support Level                                                                                             |
-| ------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------- |
-| K3d/K3s, Amazon EKS | Tested                 | Supported Kubernetes distributions undergoing testing in CI environments.                                 |
-| RKE2                | Tested                 | Supported Kubernetes distribution tested in production environments other than CI.                        |
-| Other               | Untested/Unknown state | Compatible Kubernetes distributions that are not explicitly tested, documented, or supported by UDS Core. |
+| Distribution    | Category               | Support Level                                                                                             |
+| --------------- | ---------------------- | --------------------------------------------------------------------------------------------------------- |
+| K3d, Amazon EKS | Tested                 | Supported Kubernetes distributions undergoing testing in CI environments.                                 |
+| RKE2            | Tested                 | Supported Kubernetes distribution tested in production environments other than CI.                        |
+| Other           | Untested/Unknown state | Compatible Kubernetes distributions that are not explicitly tested, documented, or supported by UDS Core. |

docs/development/flavor-specific-dev.md → docs/reference/UDS Core/flavor-specific-development-notes.md

@@ -1,7 +1,5 @@
 ---
 title: Flavor Specific Development Notes
-type: docs
-weight: 5
 ---
 
 Specific flavors of UDS Core have access and architecture restrictions when used for development work. The `upstream` flavor is generally recommended for development as it does not have any restrictions or requirements.

docs/_index.md → docs/reference/UDS Core/overview.md

@@ -1,10 +1,7 @@
 ---
-title: UDS Core
-linkTitle: UDS Core
-type: docs
-menu:
-  main:
-    weight: 30
+title: Overview
+sidebar:
+    order: 1
 ---
 
 ## What is UDS Core?

docs/deployment/prerequisites.md → docs/reference/UDS Core/prerequisites.md

@@ -1,11 +1,7 @@
 ---
 title: UDS Core Prerequisites
-type: docs
-weight: 4
 ---
 
-## UDS Core Prerequisites
-
 `UDS Core` can run in any [CNCF conformant Kubernetes distribution](https://www.cncf.io/training/certification/software-conformance/), but sometimes customizations are needed based on environments. This is an attempt to document and link to relevant information to aid in setting up your Kubernetes environment and hosts to ensure a successful `UDS Core` installation.  
 
 ### Cluster Requirements

docs/configuration/istio/ingress.md → docs/reference/configuration/ingress.md

@@ -1,7 +1,5 @@
 ---
-title: Configuring Istio Ingress
-type: docs
-weight: 1
+title: Istio Ingress
 ---
 
 UDS Core leverages Istio for ingress into the service mesh. This document provides an overview and examples of the Istio resources that UDS Core deploys to handle ingress.
@@ -38,7 +36,7 @@ packages:
 
 By default, the UDS Core Istio Gateways are set up to use the `uds.dev` domain and have a valid TLS certificate packaged.  You will want to change the domain name for your environment and provide a valid TLS certificate for this domain.
 
-You can set the TLS certs via overrides in a [UDS Bundle](https://uds.defenseunicorns.com/bundles/) (see below). UDS Core Istio Gateways default to only supporting TLS v1.3, but this can also be overridden per gateway if clients use TLS 1.2 (as seen in the tenant gateway example `value` below).
+You can set the TLS certs via overrides in a [UDS Bundle](https://uds.defenseunicorns.com/bundles/) (see below).
 
 ```yaml
 kind: UDSBundle
@@ -63,9 +61,6 @@ packages:
               path: tls.key
       istio-tenant-gateway:
         uds-istio-config:
-          values:
-            - path: tls.supportTLSV1_2
-              value: true # Add support for TLS 1.2 on this gateway, can be specified via variables if needed at deploy time
           variables:
             - name: TENANT_TLS_CERT
               description: "The TLS cert for the tenant gateway (must be base64 encoded)"
@@ -92,6 +87,6 @@ variables:
     tenant_tls_key: # base64 encoded tenant key here
 ```
 
-{{% alert-note %}}
+:::note
 If you are using Private PKI or self-signed certificates for your tenant certificates it is necessary to additionally configure `UDS_CA_CERT` with additional [trusted certificate authorities](https://uds.defenseunicorns.com/core/configuration/uds-operator/#trusted-certificate-authority).
-{{% /alert-note %}}
+:::

docs/configuration/pepr-policies.md → docs/reference/configuration/pepr-policies.md

@@ -1,7 +1,5 @@
 ---
 title: Pepr Policies
-type: docs
-weight: 3
 ---
 
 ## Common Pepr Policies for UDS Core

docs/configuration/resource-configuration-and-ha.md → docs/reference/configuration/resource-configuration-and-ha.md

@@ -1,7 +1,5 @@
 ---
 title: Resource Configuration and High Availability
-type: docs
-weight: 3.5
 ---
 
 Depending on your environment and the scale of your cluster, you might need to adjust UDS Core components for high availability or to optimize resources. Below are common areas where resource overrides can be useful when deploying UDS Core.

docs/configuration/uds-configure-policy-exemptions.md → docs/reference/configuration/uds-configure-policy-exemptions.md

@@ -1,7 +1,5 @@
 ---
 title: Configuring Policy Exemptions
-type: docs
-weight: 4
 ---
 
 By default policy exemptions ([UDSExemptions](https://github.com/defenseunicorns/uds-core/blob/uds-docs/src/pepr/operator/crd/generated/exemption-v1alpha1.ts)) are only allowed in a single namespace -- `uds-policy-exemptions`. We recognize this is not a conventional pattern in K8s, but believe it is ideal for UDS for the following reasons:

docs/configuration/uds-monitoring-metrics.md → docs/reference/configuration/uds-monitoring-metrics.md

@@ -1,7 +1,5 @@
 ---
 title: Monitoring and Metrics
-type: docs
-weight: 1
 ---
 
 UDS Core leverages Pepr to handle setup of Prometheus scraping metrics endpoints, with the particular configuration necessary to work in a STRICT mTLS (Istio) environment. We handle this via a default scrapeClass in prometheus to add the istio certs. When a monitor needs to be exempt from that tlsConfig a mutation is performed to leverage a plain scrape class without istio certs.
@@ -14,9 +12,9 @@ Generally it is beneficial to use service and pod monitor resources from existin
 1. Individual monitors can explicitly set the `exempt` scrape class to opt out of the Istio certificate configuration. This should typically only be done if your service exposes metrics on a PERMISSIVE mTLS port.
 1. If setting a `scrapeClass` is not an option due to lack of configuration in a helm chart, or for other reasons, monitors can use the `uds/skip-mutate` annotation (with any value) to have Pepr mutate the `exempt` scrape class onto the monitor.
 
-{{% alert-note %}}
+:::note
 There is a deprecated functionality in Pepr that will mutate `tlsConfig` onto individual service monitors, rather than using the scrape class approach. This has been kept in the current code temporarily to prevent any metrics downtime during the switch to `scrapeClass`. In a future release this behavior will be removed to reduce the complexity of the setup and required mutations.
-{{% /alert-note %}}
+:::
 
 ## Package CR `monitor` field
 

docs/configuration/uds-operator.md → docs/reference/configuration/uds-operator.md

@@ -1,7 +1,5 @@
 ---
 title: UDS Operator
-type: docs
-weight: 2
 ---
 
 The UDS Operator plays a pivotal role in managing the lifecycle of UDS Package Custom Resources (CRs) along with their associated resources like NetworkPolicies and Istio VirtualServices. Leveraging [Pepr](https://github.com/defenseunicorns/pepr), the operator binds watch operations to the enqueue and reconciler, taking on several key responsibilities for UDS Packages and exemptions:
@@ -163,9 +161,9 @@ spec:
         app: httpbin
 ```
 
-{{% alert-note %}}
+:::note
 The UDS Operator uses the first `redirectUris` to populate the `match.prefix` hostname and `callback_uri` in the authservice chain.
-{{% /alert-note %}}
+:::
 
 For a complete example, see [app-authservice-tenant.yaml](https://github.com/defenseunicorns/uds-core/blob/main/src/test/app-authservice-tenant.yaml)
 

docs/configuration/uds-user-groups.md → docs/reference/configuration/uds-user-groups.md

@@ -1,7 +1,5 @@
 ---
 title: User Groups
-type: docs
-weight: 5
 ---
 
 UDS Core deploys Keycloak which has some preconfigured groups that applications inherit from SSO and IDP configurations.
@@ -30,9 +28,9 @@ Neuvector [maps the groups](https://github.com/defenseunicorns/uds-core/blob/mai
 
 ## Keycloak
 
-{{% alert-note %}}
+:::note
 All groups are under the Uds Core parent group. Frequently a group will be referred to as Uds Core/Admin or Uds Core/Auditor. In the Keycloak UI this requires an additional click to get down to the sub groups.
-{{% /alert-note %}}
+:::
 
 ### Identity Providers ( IDP )