Fix links and clean lycheeignore (#1219)

* docs: fix links to cilium docs

* docs: clean lycheeignore

* docs: remove link to no longer existing blog post

.lycheeignore

@@ -1,12 +1,5 @@
 http://localhost:
-https://github.com/edgelesssys/wiki/blob/master/documentation/constellation/customer-onboarding.md
-https://github.com/edgelesssys/wiki/blob/master/documentation/rebasing_forks.md
-# medium.com based links disabled for now until Lychee gains cookie support (medium.com requires cookies to avoid infinite redirects)
-# Tracking: https://github.com/lycheeverse/lychee/issues/645
-https://blog.edgeless.systems/
-https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73
 # TODO: Remove when site fixed their TLS chain (https://github.com/edgelesssys/constellation/pull/430)
-https://www.linux-kvm.org/page/Main_Page
 https://www.ntia.gov/SBOM
 # Twitter times out on request, maybe someone pulled the plug of this subsystem...
 https://twitter.com/EdgelessSystems

docs/docs/architecture/components.md

@@ -36,7 +36,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/docs/architecture/images.md

@@ -45,5 +45,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/docs/architecture/keys.md

@@ -42,7 +42,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/docs/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).
 

docs/versioned_docs/version-2.0/architecture/components.md

@@ -39,7 +39,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/versioned_docs/version-2.0/architecture/images.md

@@ -41,5 +41,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.0/architecture/keys.md

@@ -38,7 +38,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/versioned_docs/version-2.0/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).
 

docs/versioned_docs/version-2.1/architecture/components.md

@@ -39,7 +39,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/versioned_docs/version-2.1/architecture/images.md

@@ -41,5 +41,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.1/architecture/keys.md

@@ -38,7 +38,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/versioned_docs/version-2.1/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).
 

docs/versioned_docs/version-2.2/architecture/components.md

@@ -36,7 +36,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/versioned_docs/version-2.2/architecture/images.md

@@ -45,5 +45,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.2/architecture/keys.md

@@ -42,7 +42,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/versioned_docs/version-2.2/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).
 

docs/versioned_docs/version-2.3/architecture/components.md

@@ -36,7 +36,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/versioned_docs/version-2.3/architecture/images.md

@@ -45,5 +45,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.3/architecture/keys.md

@@ -42,7 +42,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/versioned_docs/version-2.3/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).
 

docs/versioned_docs/version-2.4/architecture/components.md

@@ -36,7 +36,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/versioned_docs/version-2.4/architecture/images.md

@@ -45,5 +45,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.4/architecture/keys.md

@@ -42,7 +42,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/versioned_docs/version-2.4/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).
 

docs/versioned_docs/version-2.5/architecture/components.md

@@ -36,7 +36,7 @@ flowchart LR
 
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
+To this end, the *Bootstrapper* first downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions.
 The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 

docs/versioned_docs/version-2.5/architecture/images.md

@@ -45,5 +45,5 @@ See the section on [keys and encryption](keys.md#storage-encryption) for more in
 
 ## Kubernetes components
 
-During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
+During initialization, the [*Bootstrapper*](components.md#bootstrapper) downloads and verifies the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) as configured by the user.
 They're stored on the state partition and can be updated once new releases need to be installed.

docs/versioned_docs/version-2.5/architecture/keys.md

@@ -42,7 +42,7 @@ Each node creates its own [Curve25519](http://cr.yp.to/ecdh.html) encryption key
 A node uses another node's public key to decrypt and encrypt traffic from and to Cilium-managed endpoints running on that node.
 Connections are always encrypted peer-to-peer using [ChaCha20](http://cr.yp.to/chacha.html) with [Poly1305](http://cr.yp.to/mac.html).
 WireGuard implements [forward secrecy with key rotation every 2 minutes](https://lists.zx2c4.com/pipermail/wireguard/2017-December/002141.html).
-Cilium supports [key rotation](https://docs.cilium.io/en/stable/gettingstarted/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
+Cilium supports [key rotation](https://docs.cilium.io/en/stable/security/network/encryption-ipsec/#key-rotation) for the long-term node keys via Kubernetes secrets.
 
 ## Storage encryption
 

docs/versioned_docs/version-2.5/architecture/networking.md

@@ -2,7 +2,7 @@
 
 Constellation encrypts all pod communication using the [container network interface (CNI)](https://github.com/containernetworking/cni).
 To that end, Constellation deploys, configures, and operates the [Cilium](https://cilium.io/) CNI plugin.
-Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/gettingstarted/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
+Cilium provides [transparent encryption](https://docs.cilium.io/en/stable/security/network/encryption) for all cluster traffic using either IPSec or [WireGuard](https://www.wireguard.com/).
 Currently, Constellation only supports WireGuard as the encryption engine.
 You can read more about the cryptographic soundness of WireGuard [in their white paper](https://www.wireguard.com/papers/wireguard.pdf).