From c20bf8f5a937ababe872bff0554af9b6c72ecbf5 Mon Sep 17 00:00:00 2001 From: Karol Szwaj Date: Mon, 28 Jul 2025 17:11:30 +0200 Subject: [PATCH 1/2] Expand Gateway Namespace Mode doc on client/server auth Signed-off-by: Karol Szwaj --- .../en/latest/tasks/operations/gateway-namespace-mode.md | 6 +++++- .../en/v1.4/tasks/operations/gateway-namespace-mode.md | 6 +++++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/site/content/en/latest/tasks/operations/gateway-namespace-mode.md b/site/content/en/latest/tasks/operations/gateway-namespace-mode.md index ad7f3cd51b..332720f89d 100644 --- a/site/content/en/latest/tasks/operations/gateway-namespace-mode.md +++ b/site/content/en/latest/tasks/operations/gateway-namespace-mode.md @@ -16,8 +16,12 @@ In standard deployment mode, Envoy Gateway creates all data plane resources in t Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, providing stronger isolation and multi-tenancy. -Traditional deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. +The default (Controller Namespace) deployment mode uses mTLS where both the client and server authenticate each other. +However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. + +* **Envoy proxy pods** (running in Gateway namespaces) act as clients and authenticate using JWT tokens +* **Envoy Gateway controller pod** (running in controller namespace) acts as the server and validates JWT tokens * Only the CA certificate is available in pods running in Gateway namespaces * Client certificates are not mounted in these namespaces * The Envoy proxy still validates server certificates using the CA certificate diff --git a/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md b/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md index f71b2c688f..998b45bf2c 100644 --- a/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md +++ b/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md @@ -16,8 +16,12 @@ In standard deployment mode, Envoy Gateway creates all data plane resources in t Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, providing stronger isolation and multi-tenancy. -Traditional deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. +Traditional deployment mode uses mTLS where both the client and server authenticate each other. +However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. + +* **Envoy proxy pods** (running in Gateway namespaces) act as clients and authenticate using JWT tokens +* **Envoy Gateway controller pod** (running in controller namespace) acts as the server and validates JWT tokens * Only the CA certificate is available in pods running in Gateway namespaces * Client certificates are not mounted in these namespaces * The Envoy proxy still validates server certificates using the CA certificate From ec4561aae135a4b679faacd1caef8800286b138c Mon Sep 17 00:00:00 2001 From: Karol Szwaj Date: Fri, 1 Aug 2025 15:49:22 +0200 Subject: [PATCH 2/2] Add additional explanation to the overview Signed-off-by: Karol Szwaj --- .../en/latest/tasks/operations/gateway-namespace-mode.md | 7 ++++--- .../en/v1.4/tasks/operations/gateway-namespace-mode.md | 7 ++++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/site/content/en/latest/tasks/operations/gateway-namespace-mode.md b/site/content/en/latest/tasks/operations/gateway-namespace-mode.md index 332720f89d..3c5d841bf6 100644 --- a/site/content/en/latest/tasks/operations/gateway-namespace-mode.md +++ b/site/content/en/latest/tasks/operations/gateway-namespace-mode.md @@ -14,11 +14,12 @@ For status updates or to provide feedback, please follow our [GitHub issues](htt In standard deployment mode, Envoy Gateway creates all data plane resources in the controller namespace (typically `envoy-gateway-system`). -Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, providing stronger isolation and multi-tenancy. +The motivation behind this was to operate with minimum permissions needed to be given for Envoy Gateway controller, as the control plane and data plane was deployed in the same namespace. -The default (Controller Namespace) deployment mode uses mTLS where both the client and server authenticate each other. +Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, which provides stronger isolation and multi-tenancy compared to the Controller Namespace mode, as it isolates Envoy proxy data plane across different tenants. +This distributed architecture requires additional RBAC permissions for the Envoy Gateway controller to manage Kubernetes resources across multiple namespaces. -However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. +The default (Controller Namespace) deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. * **Envoy proxy pods** (running in Gateway namespaces) act as clients and authenticate using JWT tokens * **Envoy Gateway controller pod** (running in controller namespace) acts as the server and validates JWT tokens diff --git a/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md b/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md index 998b45bf2c..7789274463 100644 --- a/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md +++ b/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md @@ -14,11 +14,12 @@ For status updates or to provide feedback, please follow our [GitHub issues](htt In standard deployment mode, Envoy Gateway creates all data plane resources in the controller namespace (typically `envoy-gateway-system`). -Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, providing stronger isolation and multi-tenancy. +The motivation behind this was to operate with minimum permissions needed to be given for Envoy Gateway controller, as the control plane and data plane was deployed in the same namespace. -Traditional deployment mode uses mTLS where both the client and server authenticate each other. +Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, which provides stronger isolation and multi-tenancy compared to the Controller Namespace mode, as it isolates Envoy proxy data plane across different tenants. +This distributed architecture requires additional RBAC permissions for the Envoy Gateway controller to manage Kubernetes resources across multiple namespaces. -However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. +The default (Controller Namespace) deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane. * **Envoy proxy pods** (running in Gateway namespaces) act as clients and authenticate using JWT tokens * **Envoy Gateway controller pod** (running in controller namespace) acts as the server and validates JWT tokens