Merge pull request #51014 from liggitt/tenancy-links

Drop links to third-party projects from multi-tenancy page

content/en/docs/concepts/security/multi-tenancy.md

@@ -262,8 +262,6 @@ to ensure that a PersistentVolume cannot be reused across different namespaces.
 
 ### Sandboxing containers
 
-{{% thirdparty-content %}}
-
 Kubernetes pods are composed of one or more containers that execute on worker nodes.
 Containers utilize OS-level virtualization and hence offer a weaker isolation boundary than
 virtual machines that utilize hardware-based virtualization.
@@ -286,14 +284,7 @@ workloads running in a shared cluster. Running workloads in a sandbox environmen
 insulate the host from container escapes, where an attacker exploits a vulnerability to gain
 access to the host system and all the processes/files running on that host.
 
-Virtual machines and userspace kernels are two popular approaches to sandboxing. The following
-sandboxing implementations are available:
-
-* [gVisor](https://gvisor.dev/) intercepts syscalls from containers and runs them through a
-  userspace kernel, written in Go, with limited access to the underlying host.
-* [Kata Containers](https://katacontainers.io/) provide a secure container runtime that allows you to run
-  containers in a VM. The hardware virtualization available in Kata offers an added layer of
-  security for containers running untrusted code.
+Virtual machines and userspace kernels are two popular approaches to sandboxing.
 
 ### Node Isolation
 
@@ -320,8 +311,7 @@ corresponding toleration can run on them. A mutating webhook could then be used
 add tolerations and node affinities to pods deployed into tenant namespaces so that they run on a
 specific set of nodes designated for that tenant.
 
-Node isolation can be implemented using an [pod node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/)
-or a [Virtual Kubelet](https://github.com/virtual-kubelet).
+Node isolation can be implemented using [pod node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/).
 
 ## Additional Considerations
 
@@ -411,8 +401,6 @@ Specifically, the Operator should:
 
 ## Implementations
 
-{{% thirdparty-content %}}
-
 There are two primary ways to share a Kubernetes cluster for multi-tenancy: using Namespaces
 (that is, a Namespace per tenant) or by virtualizing the control plane (that is, virtual control
 plane per tenant).
@@ -456,27 +444,6 @@ resources between them. This could include managing namespace labels, namespace
 delegated access, and shared resource quotas across related namespaces. These capabilities can
 be useful in both multi-team and multi-customer scenarios.
 
-Some third-party projects that provide capabilities like this and aid in managing namespaced resources are
-listed below.
-
-{{% thirdparty-content %}}
-
-#### Multi-team tenancy
-
-* [Capsule](https://github.com/clastix/capsule)
-* [Multi Tenant Operator](https://docs.stakater.com/mto/)
-
-#### Multi-customer tenancy
-
-* [Kubeplus](https://github.com/cloud-ark/kubeplus)
-
-#### Policy engines
-
-Policy engines provide features to validate and generate tenant configurations:
-
-* [Kyverno](https://kyverno.io/)
-* [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper)
-
 ### Virtual control plane per tenant
 
 Another form of control-plane isolation is to use Kubernetes extensions to provide each tenant a
@@ -508,11 +475,3 @@ The improved isolation comes at the  cost of running and maintaining an individu
 plane per tenant. In addition, per-tenant control planes do not solve isolation problems in the
 data plane, such as node-level noisy neighbors or security threats. These must still be addressed
 separately.
-
-The Kubernetes [Cluster API - Nested (CAPN)](https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster)
-project provides an implementation of virtual control planes.
-
-#### Other implementations
-
-* [Kamaji](https://github.com/clastix/kamaji)
-* [vcluster](https://github.com/loft-sh/vcluster)