+
+
+
+The importer restores all resources in the export archive. Managed Resources get imported with the `crossplane.io/paused: "true"` annotation set. Use the `--unpause-after-import` CLI argument to automatically un-pause resources that got
+paused during backup, or remove the annotation manually.
+
+### Restore order
+
+The importer restores based on Kubernetes types. The restore order doesn't include parent/child relationships.
+
+Because Crossplane Composites create new Managed Resources if not present on the cluster, all
+Claims, Composites and Managed Resources get imported in a paused state. You can un-pause them after the restore completes.
+
+To manually un-pause managed resources after an import, remove the annotation by running:
+
+```bash
+kubectl annotate managed --all crossplane.io/paused-
+```
+
+You can also run import again with the `--unpause-after-import` flag to remove the annotations.
+
+```bash
+up controlplane migration import --unpause-after-import
+```
+
+
+[cli-command]: /reference/cli-reference
+[up-cli]: /reference/cli-reference
+[up-cli-1]: /manuals/cli/overview
+[create-command]: /reference/cli-reference
+[up-ctx]: /reference/cli-reference
diff --git a/cloud-spaces-docs/howtos/observability.md b/cloud-spaces-docs/howtos/observability.md
new file mode 100644
index 000000000..70e8e9f39
--- /dev/null
+++ b/cloud-spaces-docs/howtos/observability.md
@@ -0,0 +1,275 @@
+---
+title: Observability
+sidebar_position: 50
+description: A guide for how to use the integrated observability pipeline feature
+ in a Space.
+plan: "enterprise"
+---
+
+View the migration import
+ +```bash +$ up controlplane migration import +Importing control plane state... +✓ Reading state from the archive... Done! 👀 +✓ Importing base resources... 18 resources imported! 📥 +✓ Waiting for XRDs... Established! ⏳ +✓ Waiting for Packages... Installed and Healthy! ⏳ +✓ Importing remaining resources... 50 resources imported! 📥 +✓ Finalizing import... Done! 🎉 +``` + +"Show example of RBAC manager roles"
+```sh +kubectl get ClusterRoles -A +NAME CREATED AT +admin 2025-03-12T18:57:25Z +cluster-admin 2025-03-12T18:57:25Z +controlplane-admin 2025-03-12T18:57:56Z +controlplane-admin-spaces-extras 2025-03-12T18:57:56Z +controlplane-controller 2025-03-12T18:57:56Z +controlplane-controller-spaces-extras 2025-03-12T18:57:56Z +controlplane-edit 2025-03-12T18:57:56Z +controlplane-edit-controller-spaces-extras 2025-03-12T18:57:56Z +controlplane-edit-spaces-extras 2025-03-12T18:57:56Z +controlplane-view 2025-03-12T18:57:56Z +controlplane-view-spaces-extras 2025-03-12T18:57:56Z +crossplane 2025-03-12T18:57:54Z +crossplane-admin 2025-03-12T18:57:54Z +crossplane-browse 2025-03-12T18:57:54Z +crossplane-edit 2025-03-12T18:57:54Z +crossplane-rbac-manager 2025-03-12T18:57:54Z +crossplane-view 2025-03-12T18:57:54Z +crossplane:aggregate-to-admin 2025-03-12T18:57:54Z +crossplane:aggregate-to-browse 2025-03-12T18:57:54Z +crossplane:aggregate-to-edit 2025-03-12T18:57:54Z +crossplane:aggregate-to-view 2025-03-12T18:57:54Z +crossplane:allowed-provider-permissions 2025-03-12T18:57:54Z +crossplane:composite:xnetworks.azure.platform.upbound.io:aggregate-to-browse 2025-03-15T15:26:08Z +crossplane:composite:xnetworks.azure.platform.upbound.io:aggregate-to-crossplane 2025-03-15T15:26:08Z +crossplane:composite:xnetworks.azure.platform.upbound.io:aggregate-to-edit 2025-03-15T15:26:08Z - ```shell - kubectl get ClusterRoles -A - NAME CREATED AT - admin 2025-03-12T18:57:25Z - cluster-admin 2025-03-12T18:57:25Z - controlplane-admin 2025-03-12T18:57:56Z - controlplane-admin-spaces-extras 2025-03-12T18:57:56Z - controlplane-controller 2025-03-12T18:57:56Z - controlplane-controller-spaces-extras 2025-03-12T18:57:56Z - controlplane-edit 2025-03-12T18:57:56Z - controlplane-edit-controller-spaces-extras 2025-03-12T18:57:56Z - controlplane-edit-spaces-extras 2025-03-12T18:57:56Z - controlplane-view 2025-03-12T18:57:56Z - controlplane-view-spaces-extras 2025-03-12T18:57:56Z - crossplane 2025-03-12T18:57:54Z - crossplane-admin 2025-03-12T18:57:54Z - crossplane-browse 2025-03-12T18:57:54Z - crossplane-edit 2025-03-12T18:57:54Z - crossplane-rbac-manager 2025-03-12T18:57:54Z - crossplane-view 2025-03-12T18:57:54Z - crossplane:aggregate-to-admin 2025-03-12T18:57:54Z - crossplane:aggregate-to-browse 2025-03-12T18:57:54Z - crossplane:aggregate-to-edit 2025-03-12T18:57:54Z - crossplane:aggregate-to-view 2025-03-12T18:57:54Z - crossplane:allowed-provider-permissions 2025-03-12T18:57:54Z - crossplane:composite:xnetworks.azure.platform.upbound.io:aggregate-to-browse 2025-03-15T15:26:08Z - crossplane:composite:xnetworks.azure.platform.upbound.io:aggregate-to-crossplane 2025-03-15T15:26:08Z - crossplane:composite:xnetworks.azure.platform.upbound.io:aggregate-to-edit 2025-03-15T15:26:08Z - ``` - +```
+
+
+### Access a control plane API server via kubectl
+
+
+ 
+
+
+### Query API/Apollo
+
+
+ 
+
+
+## See also
+
+* [Upbound Spaces deployment requirements][deployment]
+* [Upbound `etcd` scaling resources][scaling]
+
+[up-ctx-workflow]: /img/up-ctx-workflow.png
+[kubectl]: /img/kubectl-workflow.png
+[query-api]: /img/query-api-workflow.png
+[spaces-workflow]: /img/up-basic-flow.png
+[rds]: https://aws.amazon.com/rds/postgresql/
+[gke-sql]: https://cloud.google.com/kubernetes-engine/docs/tutorials/stateful-workloads/postgresql
+[aks-sql]: https://learn.microsoft.com/en-us/azure/aks/deploy-postgresql-ha?tabs=azuredisk
+[deployment]: https://docs.upbound.io/spaces/howtos/self-hosted/deployment-reqs/
+[karpenter]: https://docs.aws.amazon.com/eks/latest/best-practices/karpenter.html
+[gke-autoscaling]: https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-autoscaler
+[aks-autoscaling]: https://learn.microsoft.com/en-us/azure/aks/cluster-autoscaler-overview
+[scaling]: https://docs.upbound.io/deploy/self-hosted-spaces/scaling-resources#scaling-etcd-storage
diff --git a/spaces_versioned_docs/version-1.13/howtos/control-plane-topologies.md b/spaces_versioned_docs/version-1.13/howtos/control-plane-topologies.md
new file mode 100644
index 000000000..11cd5efcf
--- /dev/null
+++ b/spaces_versioned_docs/version-1.13/howtos/control-plane-topologies.md
@@ -0,0 +1,561 @@
+---
+title: Control Plane Topologies
+sidebar_position: 15
+description: Configure scheduling of composites to remote control planes
+---
+
+
+:::important
+This feature is in private preview for select customers in Upbound Spaces. If you're interested in this deployment mode, please [contact us](https://www.upbound.io/support/contact).
+:::
+
+Upbound's _Control Plane Topology_ feature lets you build and deploy a platform
+of multiple control planes. These control planes work together for a unified platform
+experience.
+
+
+With the _Topology_ feature, you can install resource APIs that are
+reconciled by other control planes and configure the routing that occurs between
+control planes. You can also build compositions that reference other resources
+running on your control plane or elsewhere in Upbound.
+
+This guide explains how to use Control Plane Topology APIs to install, configure
+remote APIs, and build powerful compositions that reference other resources.
+
+## Benefits
+
+The Control Plane Topology feature provides the following benefits:
+
+* Decouple your platform architecture into independent offerings to improve your platform's software development lifecycle.
+* Install composite APIs from Configurations as CRDs which are fulfilled and reconciled by other control planes.
+* Route APIs to other control planes by configuring an _Environment_ resource, which define a set of routable dimensions.
+
+## How it works
+
+
+Imagine the scenario where you want to let a user reference a subnet when creating a database instance. To your control plane, the `kind: database` and `kind: subnet` are independent resources. To you as the composition author, these resources have an important relationship. It may be that:
+
+- you don't want your user to ever be able to create a database without specifying a subnet.
+- you want to let them create a subnet when they create the database, if it doesn't exist.
+- you want to allow them to reuse a subnet that got created elsewhere or gets shared by another user.
+
+In each of these scenarios, you must resort to writing complex composition logic
+to handle each case. The problem is compounded when the resource exists in a
+context separate from the current control plane's context. Imagine a scenario
+where one control plane manages Database resources and a second control plane
+manages networking resources. With the _Topology_ feature, you can offload these
+concerns to Upbound machinery.
+
+
+
+
+## Prerequisites
+
+Enable the Control Plane Topology feature in the Space you plan to run your control plane in:
+
+- Cloud Spaces: Not available yet
+- Connected Spaces: Space administrator must enable this feature
+- Disconnected Spaces: Space administrator must enable this feature
+
+
+
+## Compose resources with _ReferencedObjects_
+
+
+
+_ReferencedObject_ is a resource type available in an Upbound control plane that lets you reference other Kubernetes resources in Upbound.
+
+:::tip
+This feature is useful for composing resources that exist in a
+remote context, like another control plane. You can also use
+_ReferencedObjects_ to resolve references to any other Kubernetes object
+in the current control plane context. This could be a secret, another Crossplane
+resource, or more.
+:::
+
+### Declare the resource reference in your XRD
+
+To compose a _ReferencedObject_, you should start by adding a resource reference
+in your Composite Resource Definition (XRD). The convention for the resource
+reference follows the shape shown below:
+
+```yaml
+
+
+
+
+
+Show example for defining the reference to another composite resource
+ +```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xsqlinstances.database.platform.upbound.io +spec: + type: object + properties: + parameters: + type: object + properties: + networkRef: + type: object + properties: + apiVersion: + type: string + default: "networking.platform.upbound.io" + enum: [ "networking.platform.upbound.io" ] + grants: + type: array + default: [ "Observe" ] + items: + type: string + enum: [ "Observe" ] + kind: + type: string + default: "Network" + enum: [ "Network" ] + name: + type: string + namespace: + type: string + required: + - name +``` + +
+
+
+### Manually add the jsonPath
+
+:::important
+This step is a known limitation of the preview. We're working on tooling that
+removes the need for authors to do this step.
+:::
+
+During the preview timeframe of this feature, you must add an annotation by hand
+to the XRD. In your XRD's `metadata.annotations`, set the
+`references.upbound.io/schema` annotation. It should be a JSON string in the
+following format:
+
+```json
+{
+ "apiVersion": "references.upbound.io/v1alpha1",
+ "kind": "ReferenceSchema",
+ "references": [
+ {
+ "jsonPath": ".spec.parameters.secretRef",
+ "kinds": [
+ {
+ "apiVersion": "v1",
+ "kind": "Secret"
+ }
+ ]
+ }
+ ]
+}
+```
+
+Flatten this JSON into a string and set the annotation on your XRD. View the
+example below for an illustration:
+
+Show example for defining the reference to a secret
+```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xsqlinstances.database.platform.upbound.io +spec: + type: object + properties: + parameters: + type: object + properties: + secretRef: + type: object + properties: + apiVersion: + type: string + default: "v1" + enum: [ "v1" ] + grants: + type: array + default: [ "Observe" ] + items: + type: string + enum: [ "Observe", "Create", "Update", "Delete", "*" ] + kind: + type: string + default: "Secret" + enum: [ "Secret" ] + name: + type: string + namespace: + type: string + required: + - name +``` +
+
+
+Show example setting the references.upbound.io/schema annotation
+```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xthings.networking.acme.com + annotations: + references.upbound.io/schema: '{"apiVersion":"references.upbound.io/v1alpha1","kind":"ReferenceSchema","references":[{"jsonPath":".spec.secretRef","kinds":[{"apiVersion":"v1","kind":"Secret"}]},{"jsonPath":".spec.configMapRef","kinds":[{"apiVersion":"v1","kind":"ConfigMap"}]}]}' +``` +
+
+
+
+You can use a VSCode extension like [vscode-pretty-json][vscode-pretty-json] to make this task easier.
+
+
+### Compose a _ReferencedObject_
+
+To pair with the resource reference declared in your XRD, you must compose the referenced resource. Use the _ReferencedObject_ resource type to bring the resource into your composition. _ReferencedObject_ has the following schema:
+
+```yaml
+apiVersion: references.upbound.io/v1alpha1
+kind: ReferencedObject
+spec:
+ managementPolicies:
+ - Observe
+ deletionPolicy: Orphan
+ composite:
+ apiVersion: Show example for setting multiples references in the references.upbound.io/schema annotation
+```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xthings.networking.acme.com + annotations: + references.upbound.io/schema: '{"apiVersion":"references.upbound.io/v1alpha1","kind":"ReferenceSchema","references":[{"jsonPath":".spec.parameters.secretRef","kinds":[{"apiVersion":"v1","kind":"Secret"}]},{"jsonPath":".spec.parameters.configMapRef","kinds":[{"apiVersion":"v1","kind":"ConfigMap"}]}]}' +``` +
+
+
+By declaring a resource reference in your XRD, Upbound handles resolution of the desired resource.
+
+## Deploy APIs
+
+To configure routing resource requests between control planes, you need to deploy APIs in at least two control planes.
+
+### Deploy into a service-level control plane
+
+Package the APIs you build into a Configuration package an deploy it on a
+control plane in an Upbound Space. In Upbound, it's common to refer to the
+control plane where the Configuration package is deployed as a **service-level
+control plane**. This control plane runs the controllers that processes the API
+requests and provisions underlying resources. In a later section, you learn how
+you can use _Topology_ features to [configure routing][configure-routing].
+
+### Deploy as Remote APIs on a platform control plane
+
+You should use the same package source as deployed in the **service-level
+control planes**, but this time deploy the Configuration in a separate control
+plane as a _RemoteConfiguration_. The _RemoteConfiguration_ installs Kubernetes
+CustomResourceDefinitions for the APIs defined in the Configuration package, but
+no controllers get deployed.
+
+### Install a _RemoteConfiguration_
+
+_RemoteConfiguration_ is a resource type available in an Upbound manage control
+planes that acts like a sort of Crossplane [Configuration][configuration]
+package. Unlike standard Crossplane Configurations, which install XRDs,
+compositions, and functions into a desired control plane, _RemoteConfigurations_
+install only the CRDs for claimable composite resource types.
+
+#### Install directly
+
+Install a _RemoteConfiguration_ by defining the following and applying it to
+your control plane:
+
+```yaml
+apiVersion: pkg.upbound.io/v1alpha1
+kind: RemoteConfiguration
+metadata:
+ name: Show example for composing a resource reference to a secret
+ +```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: Composition +metadata: + name: demo-composition +spec: + compositeTypeRef: + apiVersion: networking.acme.com/v1alpha1 + kind: XThing + mode: Pipeline + pipeline: + - step: patch-and-transform + functionRef: + name: crossplane-contrib-function-patch-and-transform + input: + apiVersion: pt.fn.crossplane.io/v1beta1 + kind: Resources + resources: + - name: secret-ref-object + base: + apiVersion: references.upbound.io/v1alpha1 + kind: ReferencedObject + spec: + managementPolicies: + - Observe + deletionPolicy: Orphan + composite: + apiVersion: networking.acme.com/v1alpha1 + kind: XThing + name: TO_BE_PATCHED + jsonPath: .spec.parameters.secretRef + patches: + - type: FromCompositeFieldPath + fromFieldPath: metadata.name + toFieldPath: spec.composite.name +``` +
+
+
+Can I package any software or are there any prerequisites to be a Controller?
+ +We define a *Controller* as a software that has at least one Custom Resource Definition (CRD) and a Kubernetes controller for that CRD. This is the minimum requirement to be a *Controller*. We have some checks to enforce this at packaging time. + +
+
+
+How can I package my software as a Controller?
+ +Currently, we support Helm charts as the underlying package format for *Controllers*. As long as you have a Helm chart, you can package it as a *Controller*. + +If you don't have a Helm chart, you can't deploy the software. We only support Helm charts as the underlying package format for *Controllers*. We may extend this to support other packaging formats like Kustomize in the future. + +
+
+
+Can I package Crossplane XRDs/Compositions as a Helm chart to deploy as a Controller?
+ +This is not recommended. For packaging Crossplane XRDs/ and Compositions, we recommend using the `Configuration` package format. A helm chart only with Crossplane XRDs/Compositions does not qualify as a *Controller*. + +
+
+
+How can I override the Helm values when deploying a Controller?
+ +Overriding the Helm values is possible at two levels: +- During packaging time, in the package manifest file. +- At runtime, using a `ControllerRuntimeConfig` resource (similar to Crossplane `DeploymentRuntimeConfig`). + +
+
+
+How can I configure the helm release name and namespace for the controller?
+ +Right now, it is not possible to configure this at runtime. The package author configures release name and namespace during packaging, so it is hardcoded inside the package. Unlike a regular application that is deployed by a Helm chart, *Controllers* can only be deployed once in a given control plane, so, we hope it should be ok to rely on predefined release names and namespaces. We may consider exposing these in `ControllerRuntimeConfig` later, but, we would like to keep it opinionated unless there are strong reasons to do so. + +
+
+
+Can I deploy more than one instance of a Controller package?
+ +No, this is not possible. Remember, a *Controller* package introduces CRDs which are cluster-scoped objects. Just like one cannot deploy more than one instance of the same Crossplane Provider package today, it is not possible to deploy more than one instance of a *Controller*. + +
+
+
+Do I need a specific Crossplane version to run Controllers?
+ +Yes, you need to use Crossplane v1.19.0 or later to use *Controllers*. This is because of the changes in the Crossplane codebase to support third-party package formats in dependencies. + +Spaces `v1.12.0` supports Crossplane `v1.19` in the *Rapid* release channel. + +
+
+
+
+[cli]: /manuals/uxp/overview
+
diff --git a/spaces_versioned_docs/version-1.13/howtos/ctp-connector.md b/spaces_versioned_docs/version-1.13/howtos/ctp-connector.md
new file mode 100644
index 000000000..cf4a7b235
--- /dev/null
+++ b/spaces_versioned_docs/version-1.13/howtos/ctp-connector.md
@@ -0,0 +1,503 @@
+---
+title: Control Plane Connector
+weight: 80
+description: A guide for how to connect a Kubernetes app cluster to a control plane in Upbound using the Control Plane connector feature
+plan: "standard"
+---
+
+Can I deploy Controllers outside of an Upbound control plane? With UXP?
+ +No, *Controllers* are a proprietary package format and are only available for control planes running in Spaces hosting environments in Upbound. + +
+
+
+
+
+When an export occurs, a file named `xp-state.tar.gz` by default gets created in the working directory. You can unzip the file and all the contents of the export are all text YAML files.
+
+- Each CRD (for example `vpcs.ec2.aws.upbound.io`) gets its own directory
+which contains:
+ - A `metadata.yaml` file that contains Kubernetes Object Metadata
+ - A list of Kubernetes Categories the resource belongs to
+- A `cluster` directory that contains YAML manifests for all resources provisioned
+using the CRD.
+
+Sample contents for a Cluster with a single `XNetwork` Composite from
+[configuration-aws-network][configuration-aws-network] is show below:
+
+
+View the example export
+ +```bash +$ up controlplane migration export --exclude-resources=gotemplates.gotemplating.fn.crossplane.io,kclinputs.template.fn.crossplane.io --yes +Exporting control plane state... +✓ Scanning control plane for types to export... 121 types found! 👀 +✓ Exporting 121 Crossplane resources...60 resources exported! 📤 +✓ Exporting 3 native resources...8 resources exported! 📤 +✓ Archiving exported state... archived to "xp-state.tar.gz"! 📦 +``` + +
+
+
+
+
+The `export.yaml` file contains metadata about the export, including the configuration of the export, Crossplane information, and what's included in the export bundle.
+
+View the example cluster content
+ +```bash +├── compositionrevisions.apiextensions.crossplane.io +│ ├── cluster +│ │ ├── kcl.xnetworks.aws.platform.upbound.io-4ca6a8a.yaml +│ │ └── xnetworks.aws.platform.upbound.io-9859a34.yaml +│ └── metadata.yaml +├── configurations.pkg.crossplane.io +│ ├── cluster +│ │ └── configuration-aws-network.yaml +│ └── metadata.yaml +├── deploymentruntimeconfigs.pkg.crossplane.io +│ ├── cluster +│ │ └── default.yaml +│ └── metadata.yaml +├── export.yaml +├── functions.pkg.crossplane.io +│ ├── cluster +│ │ ├── crossplane-contrib-function-auto-ready.yaml +│ │ ├── crossplane-contrib-function-go-templating.yaml +│ │ └── crossplane-contrib-function-kcl.yaml +│ └── metadata.yaml +├── internetgateways.ec2.aws.upbound.io +│ ├── cluster +│ │ └── borrelli-backup-test-xgl4q.yaml +│ └── metadata.yaml +├── mainroutetableassociations.ec2.aws.upbound.io +│ ├── cluster +│ │ └── borrelli-backup-test-t2qh7.yaml +│ └── metadata.yaml +├── namespaces +│ └── cluster +│ ├── crossplane-system.yaml +│ ├── default.yaml +│ └── upbound-system.yaml +├── providerconfigs.aws.upbound.io +│ ├── cluster +│ │ └── default.yaml +│ └── metadata.yaml +├── providerconfigusages.aws.upbound.io +│ ├── cluster +│ │ ├── 0a2a3ec6-ef13-45f9-9cf0-63af7f4a6b6b.yaml +...redacted +│ │ └── f7092b0f-3a78-4bfe-82c8-57e5085a9b11.yaml +│ └── metadata.yaml +├── providers.pkg.crossplane.io +│ ├── cluster +│ │ ├── upbound-provider-aws-ec2.yaml +│ │ └── upbound-provider-family-aws.yaml +│ └── metadata.yaml +├── routes.ec2.aws.upbound.io +│ ├── cluster +│ │ └── borrelli-backup-test-dt9cj.yaml +│ └── metadata.yaml +├── routetableassociations.ec2.aws.upbound.io +│ ├── cluster +│ │ ├── borrelli-backup-test-mr2sd.yaml +│ │ ├── borrelli-backup-test-ngq5h.yaml +│ │ ├── borrelli-backup-test-nrkgg.yaml +│ │ └── borrelli-backup-test-wq752.yaml +│ └── metadata.yaml +├── routetables.ec2.aws.upbound.io +│ ├── cluster +│ │ └── borrelli-backup-test-dv4mb.yaml +│ └── metadata.yaml +├── secrets +│ └── namespaces +│ ├── crossplane-system +│ │ ├── cert-token-signing-gateway-pub.yaml +│ │ ├── mxp-hostcluster-certs.yaml +│ │ ├── package-pull-secret.yaml +│ │ └── xgql-tls.yaml +│ └── upbound-system +│ └── aws-creds.yaml +├── securitygrouprules.ec2.aws.upbound.io +│ ├── cluster +│ │ ├── borrelli-backup-test-472f4.yaml +│ │ └── borrelli-backup-test-qftmw.yaml +│ └── metadata.yaml +├── securitygroups.ec2.aws.upbound.io +│ ├── cluster +│ │ └── borrelli-backup-test-w5jch.yaml +│ └── metadata.yaml +├── storeconfigs.secrets.crossplane.io +│ ├── cluster +│ │ └── default.yaml +│ └── metadata.yaml +├── subnets.ec2.aws.upbound.io +│ ├── cluster +│ │ ├── borrelli-backup-test-8btj6.yaml +│ │ ├── borrelli-backup-test-gbmrm.yaml +│ │ ├── borrelli-backup-test-m7kh7.yaml +│ │ └── borrelli-backup-test-nttt5.yaml +│ └── metadata.yaml +├── vpcs.ec2.aws.upbound.io +│ ├── cluster +│ │ └── borrelli-backup-test-7hwgh.yaml +│ └── metadata.yaml +└── xnetworks.aws.platform.upbound.io +├── cluster +│ └── borrelli-backup-test.yaml +└── metadata.yaml +43 directories, 87 files +``` + +
+
+
+
+### Skipped resources
+
+Along with to the resources excluded via CLI options, the following resources aren't
+included in the backup:
+
+- The `kube-root-ca.crt` ConfigMap, since this is cluster-specific
+- Resources directly managed via Helm (ArgoCD's helm implementation, which templates
+Helm resources and then applies them, get included in the backup). The migration creates the exclusion list by looking for:
+ - Any Resource with the label `"app.kubernetes.io/managed-by" == "Helm"`
+ - Kubernetes Secrets with the label prefix `helm.sh/release`. example, `helm.sh/release.v1`
+- Resources installed via a Crossplane package. These have an `ownerReference` with
+a prefix `pkg.crossplane.io`. The expectation is that during import, the Crossplane Package Manager bears responsibility for installing the resources.
+- Crossplane Locks: Any `Lock.pkg.crossplane.io` resource isn't included in the
+export.
+
+## Restore
+
+The following is an example of a successful import run. At the end of the import, all Managed Resources are in a paused state.
+
+View the export
+ +```yaml +version: v1alpha1 +exportedAt: 2025-01-06T17:39:53.173222Z +options: + excludedNamespaces: + - kube-system + - kube-public + - kube-node-lease + - local-path-storage + includedResources: + - namespaces + - configmaps + - secrets + excludedResources: + - gotemplates.gotemplating.fn.crossplane.io + - kclinputs.template.fn.crossplane.io +crossplane: + distribution: universal-crossplane + namespace: crossplane-system + version: 1.17.3-up.1 + featureFlags: + - --enable-provider-identity + - --enable-environment-configs + - --enable-composition-functions + - --enable-usages +stats: + total: 68 + nativeResources: + configmaps: 0 + namespaces: 3 + secrets: 5 + customResources: + amicopies.ec2.aws.upbound.io: 0 + amilaunchpermissions.ec2.aws.upbound.io: 0 + amis.ec2.aws.upbound.io: 0 + availabilityzonegroups.ec2.aws.upbound.io: 0 + capacityreservations.ec2.aws.upbound.io: 0 + carriergateways.ec2.aws.upbound.io: 0 + compositeresourcedefinitions.apiextensions.crossplane.io: 0 + compositionrevisions.apiextensions.crossplane.io: 2 + compositions.apiextensions.crossplane.io: 0 + configurationrevisions.pkg.crossplane.io: 0 + configurations.pkg.crossplane.io: 1 +...redacted +``` + +
+
+
+
+Your scenario may involve migrating resources which already exist through other automation on the platform. When executing an import in these circumstances, the importer applies the new manifests to the cluster. If the resource already exists, the restore sets fields to what's in the backup.
+
+The importer restores all resources in the export archive. Managed Resources get imported with the `crossplane.io/paused: "true"` annotation set. Use the `--unpause-after-import` CLI argument to automatically un-pause resources that got
+paused during backup, or remove the annotation manually.
+
+### Restore order
+
+The importer restores based on Kubernetes types. The restore order doesn't include parent/child relationships.
+
+Because Crossplane Composites create new Managed Resources if not present on the cluster, all
+Claims, Composites and Managed Resources get imported in a paused state. You can un-pause them after the restore completes.
+
+The first step of import is installing Base Resources into the cluster. These resources (such has
+packages and XRDs) must be ready before proceeding with the import.
+Base Resources are:
+
+- Kubernetes Resources
+ - ConfigMaps
+ - Namespaces
+ - Secrets
+- Crossplane Resources
+ - ControllerConfigs: `controllerconfigs.pkg.crossplane.io`
+ - DeploymentRuntimeConfigs: `deploymentruntimeconfigs.pkg.crossplane.io`
+ - StoreConfigs: `storeconfigs.secrets.crossplane.io`
+- Crossplane Packages
+ - Providers: `providers.pkg.crossplane.io`
+ - Functions: `functions.pkg.crossplane.io`
+ - Configurations: `configurations.pkg.crossplane.io`
+
+Restore waits for the base resources to be `Ready` before moving on to the next step. Next, restore walks through the archive and restores all the manifests present.
+
+During import, the `crossplane.io/paused` annotation gets added to Managed Resources, Claims
+and Composites.
+
+To manually un-pause managed resources after an import, remove the annotation by running:
+
+```bash
+kubectl annotate managed --all crossplane.io/paused-
+```
+
+You can also run import again with the `--unpause-after-import` flag to remove the annotations.
+
+```bash
+up controlplane migration import --unpause-after-import
+```
+
+### Restoring resource status
+
+The importer applies the status of all resources during import. The importer determines if the CRD version has a status field defined based on the stored CRD version.
+
+
+[cli-command]: /reference/cli-reference
+[up-cli]: /reference/cli-reference
+[up-cli-1]: /manuals/cli/overview
+[create-command]: /reference/cli-reference
+[up-ctx]: /reference/cli-reference
+[configuration-aws-network]: https://marketplace.upbound.io/configurations/upbound/configuration-aws-network
diff --git a/spaces_versioned_docs/version-1.13/howtos/observability.md b/spaces_versioned_docs/version-1.13/howtos/observability.md
new file mode 100644
index 000000000..0ddd1f966
--- /dev/null
+++ b/spaces_versioned_docs/version-1.13/howtos/observability.md
@@ -0,0 +1,375 @@
+---
+title: Observability
+sidebar_position: 50
+description: A guide for how to use the integrated observability pipeline feature
+ in a Space.
+plan: "enterprise"
+---
+
+View the migration import
+ +```bash +$ up controlplane migration import +Importing control plane state... +✓ Reading state from the archive... Done! 👀 +✓ Importing base resources... 18 resources imported! 📥 +✓ Waiting for XRDs... Established! ⏳ +✓ Waiting for Packages... Installed and Healthy! ⏳ +✓ Importing remaining resources... 50 resources imported! 📥 +✓ Finalizing import... Done! 🎉 +``` + +
+
+
+### Access a control plane API server via kubectl
+
+
+
+
+
+### Query API/Apollo
+
+
+
+
+
+## See also
+
+* [Upbound Spaces deployment requirements][deployment]
+* [Upbound `etcd` scaling resources][scaling]
+
+[up-ctx-workflow]: /img/up-ctx-workflow.png
+[kubectl]: /img/kubectl-workflow.png
+[query-api]: /img/query-api-workflow.png
+[spaces-workflow]: /img/up-basic-flow.png
+[rds]: https://aws.amazon.com/rds/postgresql/
+[gke-sql]: https://cloud.google.com/kubernetes-engine/docs/tutorials/stateful-workloads/postgresql
+[aks-sql]: https://learn.microsoft.com/en-us/azure/aks/deploy-postgresql-ha?tabs=azuredisk
+[deployment]: https://docs.upbound.io/spaces/howtos/self-hosted/deployment-reqs/
+[karpenter]: https://docs.aws.amazon.com/eks/latest/best-practices/karpenter.html
+[gke-autoscaling]: https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-autoscaler
+[aks-autoscaling]: https://learn.microsoft.com/en-us/azure/aks/cluster-autoscaler-overview
+[scaling]: https://docs.upbound.io/deploy/self-hosted-spaces/scaling-resources#scaling-etcd-storage
diff --git a/spaces_versioned_docs/version-1.14/howtos/control-plane-topologies.md b/spaces_versioned_docs/version-1.14/howtos/control-plane-topologies.md
new file mode 100644
index 000000000..11cd5efcf
--- /dev/null
+++ b/spaces_versioned_docs/version-1.14/howtos/control-plane-topologies.md
@@ -0,0 +1,561 @@
+---
+title: Control Plane Topologies
+sidebar_position: 15
+description: Configure scheduling of composites to remote control planes
+---
+
+
+:::important
+This feature is in private preview for select customers in Upbound Spaces. If you're interested in this deployment mode, please [contact us](https://www.upbound.io/support/contact).
+:::
+
+Upbound's _Control Plane Topology_ feature lets you build and deploy a platform
+of multiple control planes. These control planes work together for a unified platform
+experience.
+
+
+With the _Topology_ feature, you can install resource APIs that are
+reconciled by other control planes and configure the routing that occurs between
+control planes. You can also build compositions that reference other resources
+running on your control plane or elsewhere in Upbound.
+
+This guide explains how to use Control Plane Topology APIs to install, configure
+remote APIs, and build powerful compositions that reference other resources.
+
+## Benefits
+
+The Control Plane Topology feature provides the following benefits:
+
+* Decouple your platform architecture into independent offerings to improve your platform's software development lifecycle.
+* Install composite APIs from Configurations as CRDs which are fulfilled and reconciled by other control planes.
+* Route APIs to other control planes by configuring an _Environment_ resource, which define a set of routable dimensions.
+
+## How it works
+
+
+Imagine the scenario where you want to let a user reference a subnet when creating a database instance. To your control plane, the `kind: database` and `kind: subnet` are independent resources. To you as the composition author, these resources have an important relationship. It may be that:
+
+- you don't want your user to ever be able to create a database without specifying a subnet.
+- you want to let them create a subnet when they create the database, if it doesn't exist.
+- you want to allow them to reuse a subnet that got created elsewhere or gets shared by another user.
+
+In each of these scenarios, you must resort to writing complex composition logic
+to handle each case. The problem is compounded when the resource exists in a
+context separate from the current control plane's context. Imagine a scenario
+where one control plane manages Database resources and a second control plane
+manages networking resources. With the _Topology_ feature, you can offload these
+concerns to Upbound machinery.
+
+
+
+
+## Prerequisites
+
+Enable the Control Plane Topology feature in the Space you plan to run your control plane in:
+
+- Cloud Spaces: Not available yet
+- Connected Spaces: Space administrator must enable this feature
+- Disconnected Spaces: Space administrator must enable this feature
+
+
+
+## Compose resources with _ReferencedObjects_
+
+
+
+_ReferencedObject_ is a resource type available in an Upbound control plane that lets you reference other Kubernetes resources in Upbound.
+
+:::tip
+This feature is useful for composing resources that exist in a
+remote context, like another control plane. You can also use
+_ReferencedObjects_ to resolve references to any other Kubernetes object
+in the current control plane context. This could be a secret, another Crossplane
+resource, or more.
+:::
+
+### Declare the resource reference in your XRD
+
+To compose a _ReferencedObject_, you should start by adding a resource reference
+in your Composite Resource Definition (XRD). The convention for the resource
+reference follows the shape shown below:
+
+```yaml
+
+
+
+
+
+Show example for defining the reference to another composite resource
+ +```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xsqlinstances.database.platform.upbound.io +spec: + type: object + properties: + parameters: + type: object + properties: + networkRef: + type: object + properties: + apiVersion: + type: string + default: "networking.platform.upbound.io" + enum: [ "networking.platform.upbound.io" ] + grants: + type: array + default: [ "Observe" ] + items: + type: string + enum: [ "Observe" ] + kind: + type: string + default: "Network" + enum: [ "Network" ] + name: + type: string + namespace: + type: string + required: + - name +``` + +
+
+
+### Manually add the jsonPath
+
+:::important
+This step is a known limitation of the preview. We're working on tooling that
+removes the need for authors to do this step.
+:::
+
+During the preview timeframe of this feature, you must add an annotation by hand
+to the XRD. In your XRD's `metadata.annotations`, set the
+`references.upbound.io/schema` annotation. It should be a JSON string in the
+following format:
+
+```json
+{
+ "apiVersion": "references.upbound.io/v1alpha1",
+ "kind": "ReferenceSchema",
+ "references": [
+ {
+ "jsonPath": ".spec.parameters.secretRef",
+ "kinds": [
+ {
+ "apiVersion": "v1",
+ "kind": "Secret"
+ }
+ ]
+ }
+ ]
+}
+```
+
+Flatten this JSON into a string and set the annotation on your XRD. View the
+example below for an illustration:
+
+Show example for defining the reference to a secret
+```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xsqlinstances.database.platform.upbound.io +spec: + type: object + properties: + parameters: + type: object + properties: + secretRef: + type: object + properties: + apiVersion: + type: string + default: "v1" + enum: [ "v1" ] + grants: + type: array + default: [ "Observe" ] + items: + type: string + enum: [ "Observe", "Create", "Update", "Delete", "*" ] + kind: + type: string + default: "Secret" + enum: [ "Secret" ] + name: + type: string + namespace: + type: string + required: + - name +``` +
+
+
+Show example setting the references.upbound.io/schema annotation
+```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xthings.networking.acme.com + annotations: + references.upbound.io/schema: '{"apiVersion":"references.upbound.io/v1alpha1","kind":"ReferenceSchema","references":[{"jsonPath":".spec.secretRef","kinds":[{"apiVersion":"v1","kind":"Secret"}]},{"jsonPath":".spec.configMapRef","kinds":[{"apiVersion":"v1","kind":"ConfigMap"}]}]}' +``` +
+
+
+
+You can use a VSCode extension like [vscode-pretty-json][vscode-pretty-json] to make this task easier.
+
+
+### Compose a _ReferencedObject_
+
+To pair with the resource reference declared in your XRD, you must compose the referenced resource. Use the _ReferencedObject_ resource type to bring the resource into your composition. _ReferencedObject_ has the following schema:
+
+```yaml
+apiVersion: references.upbound.io/v1alpha1
+kind: ReferencedObject
+spec:
+ managementPolicies:
+ - Observe
+ deletionPolicy: Orphan
+ composite:
+ apiVersion: Show example for setting multiples references in the references.upbound.io/schema annotation
+```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: CompositeResourceDefinition +metadata: + name: xthings.networking.acme.com + annotations: + references.upbound.io/schema: '{"apiVersion":"references.upbound.io/v1alpha1","kind":"ReferenceSchema","references":[{"jsonPath":".spec.parameters.secretRef","kinds":[{"apiVersion":"v1","kind":"Secret"}]},{"jsonPath":".spec.parameters.configMapRef","kinds":[{"apiVersion":"v1","kind":"ConfigMap"}]}]}' +``` +
+
+
+By declaring a resource reference in your XRD, Upbound handles resolution of the desired resource.
+
+## Deploy APIs
+
+To configure routing resource requests between control planes, you need to deploy APIs in at least two control planes.
+
+### Deploy into a service-level control plane
+
+Package the APIs you build into a Configuration package an deploy it on a
+control plane in an Upbound Space. In Upbound, it's common to refer to the
+control plane where the Configuration package is deployed as a **service-level
+control plane**. This control plane runs the controllers that processes the API
+requests and provisions underlying resources. In a later section, you learn how
+you can use _Topology_ features to [configure routing][configure-routing].
+
+### Deploy as Remote APIs on a platform control plane
+
+You should use the same package source as deployed in the **service-level
+control planes**, but this time deploy the Configuration in a separate control
+plane as a _RemoteConfiguration_. The _RemoteConfiguration_ installs Kubernetes
+CustomResourceDefinitions for the APIs defined in the Configuration package, but
+no controllers get deployed.
+
+### Install a _RemoteConfiguration_
+
+_RemoteConfiguration_ is a resource type available in an Upbound manage control
+planes that acts like a sort of Crossplane [Configuration][configuration]
+package. Unlike standard Crossplane Configurations, which install XRDs,
+compositions, and functions into a desired control plane, _RemoteConfigurations_
+install only the CRDs for claimable composite resource types.
+
+#### Install directly
+
+Install a _RemoteConfiguration_ by defining the following and applying it to
+your control plane:
+
+```yaml
+apiVersion: pkg.upbound.io/v1alpha1
+kind: RemoteConfiguration
+metadata:
+ name: Show example for composing a resource reference to a secret
+ +```yaml +apiVersion: apiextensions.crossplane.io/v1 +kind: Composition +metadata: + name: demo-composition +spec: + compositeTypeRef: + apiVersion: networking.acme.com/v1alpha1 + kind: XThing + mode: Pipeline + pipeline: + - step: patch-and-transform + functionRef: + name: crossplane-contrib-function-patch-and-transform + input: + apiVersion: pt.fn.crossplane.io/v1beta1 + kind: Resources + resources: + - name: secret-ref-object + base: + apiVersion: references.upbound.io/v1alpha1 + kind: ReferencedObject + spec: + managementPolicies: + - Observe + deletionPolicy: Orphan + composite: + apiVersion: networking.acme.com/v1alpha1 + kind: XThing + name: TO_BE_PATCHED + jsonPath: .spec.parameters.secretRef + patches: + - type: FromCompositeFieldPath + fromFieldPath: metadata.name + toFieldPath: spec.composite.name +``` +
+
+
+Can I package any software or are there any prerequisites to be a Controller?
+ +We define a *Controller* as a software that has at least one Custom Resource Definition (CRD) and a Kubernetes controller for that CRD. This is the minimum requirement to be a *Controller*. We have some checks to enforce this at packaging time. + +
+
+
+How can I package my software as a Controller?
+ +Currently, we support Helm charts as the underlying package format for *Controllers*. As long as you have a Helm chart, you can package it as a *Controller*. + +If you don't have a Helm chart, you can't deploy the software. We only support Helm charts as the underlying package format for *Controllers*. We may extend this to support other packaging formats like Kustomize in the future. + +
+
+
+Can I package Crossplane XRDs/Compositions as a Helm chart to deploy as a Controller?
+ +This is not recommended. For packaging Crossplane XRDs/ and Compositions, we recommend using the `Configuration` package format. A helm chart only with Crossplane XRDs/Compositions does not qualify as a *Controller*. + +
+
+
+How can I override the Helm values when deploying a Controller?
+ +Overriding the Helm values is possible at two levels: +- During packaging time, in the package manifest file. +- At runtime, using a `ControllerRuntimeConfig` resource (similar to Crossplane `DeploymentRuntimeConfig`). + +
+
+
+How can I configure the helm release name and namespace for the controller?
+ +Right now, it is not possible to configure this at runtime. The package author configures release name and namespace during packaging, so it is hardcoded inside the package. Unlike a regular application that is deployed by a Helm chart, *Controllers* can only be deployed once in a given control plane, so, we hope it should be ok to rely on predefined release names and namespaces. We may consider exposing these in `ControllerRuntimeConfig` later, but, we would like to keep it opinionated unless there are strong reasons to do so. + +
+
+
+Can I deploy more than one instance of a Controller package?
+ +No, this is not possible. Remember, a *Controller* package introduces CRDs which are cluster-scoped objects. Just like one cannot deploy more than one instance of the same Crossplane Provider package today, it is not possible to deploy more than one instance of a *Controller*. + +
+
+
+Do I need a specific Crossplane version to run Controllers?
+ +Yes, you need to use Crossplane v1.19.0 or later to use *Controllers*. This is because of the changes in the Crossplane codebase to support third-party package formats in dependencies. + +Spaces `v1.12.0` supports Crossplane `v1.19` in the *Rapid* release channel. + +
+
+
+
+[cli]: /manuals/uxp/overview
+
diff --git a/spaces_versioned_docs/version-1.14/howtos/ctp-audit-logs.md b/spaces_versioned_docs/version-1.14/howtos/ctp-audit-logs.md
new file mode 100644
index 000000000..e387b2873
--- /dev/null
+++ b/spaces_versioned_docs/version-1.14/howtos/ctp-audit-logs.md
@@ -0,0 +1,544 @@
+---
+title: Control plane audit logging
+---
+
+This guide explains how to enable and configure audit logging for control planes
+in Self-Hosted Upbound Spaces.
+
+Starting in Spaces `v1.14.0`, each control plane contains an API server that
+supports audit log collection. You can use audit logging to track creation,
+updates, and deletions of Crossplane resources. Control plane audit logs
+use observability features to collect audit logs with `SharedTelemetryConfig` and
+send logs to an OpenTelemetry (`OTEL`) collector.
+
+
+## Prerequisites
+
+Before you begin, make sure you have:
+
+* Spaces `v1.14.0` or greater
+* Admin access to your Spaces host cluster
+* `kubectl` configured to access the host cluster
+* `helm` installed
+* `yq` installed
+* `up` CLI installed and logged in to your organization
+
+## Enable observability
+
+
+Observability graduated to General Available in `v1.14.0` but is disabled by
+default.
+
+
+Can I deploy Controllers outside of an Upbound control plane? With UXP?
+ +No, *Controllers* are a proprietary package format and are only available for control planes running in Spaces hosting environments in Upbound. + +
+```yaml title="ctp-audit.yaml"
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: audit-test
+---
+apiVersion: spaces.upbound.io/v1beta1
+kind: ControlPlane
+metadata:
+ labels:
+ audit-enabled: "true"
+ name: ctp1
+ namespace: audit-test
+spec:
+ writeConnectionSecretToRef:
+ name: kubeconfig-ctp1
+ namespace: audit-test
+```
+
+
+The `metadata.labels` section contains the
+```yaml title="sharedtelemetryconfig.yaml"
+apiVersion: observability.spaces.upbound.io/v1alpha1
+kind: SharedTelemetryConfig
+metadata:
+ name: apiserver-audit
+ namespace: audit-test
+spec:
+ apiServer:
+ audit:
+ enabled: true
+ exporters:
+ otlphttp:
+ endpoint: http://otel-lgtm.observability:4318
+ exportPipeline:
+ logs: [otlphttp]
+ controlPlaneSelector:
+ labelSelectors:
+ - matchLabels:
+ audit-enabled: "true"
+```
+
+
+This configuration:
+
+* Sets
+
+
+## Customize the audit policy
+
+Spaces `v1.14.0` includes a default audit policy. You can customize this policy
+by creating a configuration file and passing the values to
+`observability.collectors.apiServer.auditPolicy` in the helm values file.
+
+An example custom audit policy:
+
+```yaml
+observability:
+ controlPlanes:
+ apiServer:
+ auditPolicy: |
+ apiVersion: audit.k8s.io/v1
+ kind: Policy
+ rules:
+ # ============================================================================
+ # RULE 1: Exclude health check and version endpoints
+ # ============================================================================
+ - level: None
+ nonResourceURLs:
+ - '/healthz*'
+ - '/readyz*'
+ - /version
+ # ============================================================================
+ # RULE 2: ConfigMaps - Write operations only
+ # ============================================================================
+ - level: Metadata
+ resources:
+ - group: ""
+ resources:
+ - configmaps
+ verbs:
+ - create
+ - update
+ - patch
+ - delete
+ omitStages:
+ - RequestReceived
+ - ResponseStarted
+ # ============================================================================
+ # RULE 3: Secrets - ALL operations
+ # ============================================================================
+ - level: Metadata
+ resources:
+ - group: ""
+ resources:
+ - secrets
+ verbs:
+ - get
+ - list
+ - watch
+ - create
+ - update
+ - patch
+ - delete
+ omitStages:
+ - RequestReceived
+ - ResponseStarted
+ # ============================================================================
+ # RULE 4: Global exclusion of read-only operations
+ # ============================================================================
+ - level: None
+ verbs:
+ - get
+ - list
+ - watch
+ # ==========================================================================
+ # RULE 5: Exclude standard Kubernetes resources from write operation logging
+ # ==========================================================================
+ - level: None
+ resources:
+ - group: ""
+ - group: "apps"
+ - group: "networking.k8s.io"
+ - group: "policy"
+ - group: "rbac.authorization.k8s.io"
+ - group: "storage.k8s.io"
+ - group: "batch"
+ - group: "autoscaling"
+ - group: "metrics.k8s.io"
+ - group: "node.k8s.io"
+ - group: "scheduling.k8s.io"
+ - group: "coordination.k8s.io"
+ - group: "discovery.k8s.io"
+ - group: "events.k8s.io"
+ - group: "flowcontrol.apiserver.k8s.io"
+ - group: "internal.apiserver.k8s.io"
+ - group: "authentication.k8s.io"
+ - group: "authorization.k8s.io"
+ - group: "admissionregistration.k8s.io"
+ verbs:
+ - create
+ - update
+ - patch
+ - delete
+ # ============================================================================
+ # RULE 6: Catch-all for ALL custom resources and any missed resources
+ # ============================================================================
+ - level: Metadata
+ verbs:
+ - create
+ - update
+ - patch
+ - delete
+ omitStages:
+ - RequestReceived
+ - ResponseStarted
+ # ============================================================================
+ # RULE 7: Final catch-all - exclude everything else
+ # ============================================================================
+ - level: None
+ omitStages:
+ - RequestReceived
+ - ResponseStarted
+```
+You can apply this policy during Spaces installation or upgrade using the helm values file.
+
+Audit policies use rules evaluated in order from top to bottom where the first
+matching rule applies. Control plane audit policies follow Kubernetes conventions and use the
+following logging levels:
+
+* **None** - Don't log events matching this rule
+* **Metadata** - Log request metadata (user, timestamp, resource, verb) but not request or response bodies
+* **Request** - Log metadata and request body but not response body
+* **RequestResponse** - Log metadata, request body, and response body
+
+For more information, review the Kubernetes [Auditing] documentation.
+
+## Disable audit logging
+
+You can disable audit logging on a control plane by removing it from the
+`SharedTelemetryConfig` selector or by deleting the `SharedTelemetryConfig`.
+
+### Disable for specific control planes
+
+Remove the `audit-enabled` label from control planes that should stop sending audit logs:
+
+```bash
+kubectl label controlplane