Skip to content

Commit 06bbde3

Browse files
Merge pull request #6138 from DharshanSR/envoy-doc
Add Envoy Gateway configuration and Backend TLS setup instructions for Kubernetes deployment
2 parents f4e6691 + 8a41391 commit 06bbde3

1 file changed

Lines changed: 137 additions & 3 deletions

File tree

en/includes/deploy/deploy-is-on-kubernetes.md

Lines changed: 137 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,21 @@ Make sure you have the following before starting this guide.
3131

3232
- A running Kubernetes cluster (e.g. [minikube](https://kubernetes.io/docs/tasks/tools/#minikube){:target="_blank"} or an existing cluster).
3333

34-
- A Kubernetes [Ingress-Nginx Controller](https://kubernetes.github.io/ingress-nginx/deploy/){:target="_blank"}.
34+
- One of the following Kubernetes traffic management options, depending on the deployment pattern you choose:
35+
36+
- **Option 1: Kubernetes Ingress pattern** — Install a Kubernetes [Ingress-Nginx Controller](https://kubernetes.github.io/ingress-nginx/deploy/){:target="_blank"}.
37+
38+
- **Option 2: Kubernetes Gateway API pattern** — Install Envoy Gateway. You must install the Envoy Gateway Controller with Experimental Features and Extension APIs enabled. These are required to support `BackendTLSPolicy` for secure backend communication and `EnvoyPatchPolicy` for session persistence.
39+
40+
```
41+
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \
42+
--version v1.7.0 \
43+
-n envoy-gateway-system \
44+
--create-namespace \
45+
--set envoyGateway.gateway.experimentalFeatures.enabled=true \
46+
--set config.envoyGateway.extensionApis.enableBackend=true \
47+
--set config.envoyGateway.extensionApis.enableEnvoyPatchPolicy=true
48+
```
3549
3650
## Step 1: Set up environment variables
3751
@@ -199,7 +213,127 @@ If your hostname is backed by a DNS service, create a DNS record that maps the h
199213
<EXTERNAL-IP> wso2is.com
200214
```
201215

202-
## Step 7: Access {{product_name}}
216+
## Step 7: (Optional) Configure Backend TLS for Envoy Gateway
217+
218+
!!! note
219+
This step is only required if you are using Envoy Gateway.
220+
221+
When using Envoy Gateway, the communication between the Gateway and the WSO2 Identity Server pods is secured via Backend TLS. To establish this trust, Envoy must verify the certificate presented by the WSO2 IS.
222+
223+
You must provide a Kubernetes ConfigMap containing the CA certificate that signed the WSO2 IS TLS certificate.
224+
225+
Follow the steps below to generate a self-signed CA certificate and sign the WSO2 IS Keystore certificate to ensure successful Backend TLS communication between Envoy and the backend Identity Server.
226+
227+
!!! note
228+
WSO2 Identity Server supports using multiple, purpose‑specific keystores — for example, separate keystores for Primary, Internal, and TLS use cases. In production it's recommended to maintain distinct keystores so that keys used for different functions (such as internal data encryption, token signing, and TLS communication) can be managed and rotated independently. For Backend TLS communication with Envoy Gateway, only the TLS keystore (which holds the certificate used for HTTPS/TLS connections) is required.
229+
230+
### Step 7a: Generate a Self-Signed Certificate Authority (CA)
231+
232+
First, create a private key and a self-signed root certificate to act as your internal CA.
233+
234+
```shell
235+
# Generate CA private key
236+
openssl genrsa -out wso2carbon-ca.key 2048
237+
238+
# Generate Root CA certificate
239+
openssl req -x509 -new -nodes -key wso2carbon-ca.key -sha256 -days 3650 \
240+
-out wso2carbon-ca.crt \
241+
-subj "/CN=WSO2 Carbon Internal CA/O=WSO2"
242+
```
243+
244+
### Step 7b: Create a Server Configuration File
245+
246+
To ensure the certificate is compatible with Envoy Gateway's strict validation, you must include the keyUsage and Subject Alternative Name (SAN). Create a file named `server.conf`.
247+
248+
```
249+
[req]
250+
distinguished_name = req_distinguished_name
251+
req_extensions = v3_req
252+
prompt = no
253+
254+
[req_distinguished_name]
255+
CN = localhost
256+
257+
[v3_req]
258+
keyUsage = digitalSignature, keyEncipherment
259+
extendedKeyUsage = serverAuth
260+
subjectAltName = @alt_names
261+
262+
[alt_names]
263+
DNS.1 = localhost
264+
```
265+
266+
### Step 7c: Generate and Sign the WSO2 IS Certificate
267+
268+
Generate a new private key for the WSO2 IS Keystore and sign the request using the CA created in Step 7a.
269+
270+
```shell
271+
# Generate private key for WSO2 IS
272+
openssl genrsa -out wso2carbon.key 2048
273+
274+
# Create a Certificate Signing Request (CSR)
275+
openssl req -new -key wso2carbon.key -out wso2carbon.csr -config server.conf
276+
277+
# Sign the CSR with your Internal CA
278+
openssl x509 -req -in wso2carbon.csr \
279+
-CA wso2carbon-ca.crt \
280+
-CAkey wso2carbon-ca.key \
281+
-CAcreateserial \
282+
-out wso2carbon.crt \
283+
-days 365 -sha256 \
284+
-extfile server.conf \
285+
-extensions v3_req
286+
```
287+
288+
### Step 7d: Package into a PKCS12 Keystore
289+
290+
WSO2 Identity Server prefers the PKCS12 format for its Keystore. Convert the certificate and key into a `.p12` file.
291+
292+
```shell
293+
openssl pkcs12 -export -in wso2carbon.crt -inkey wso2carbon.key \
294+
-out wso2carbon.p12 -name wso2carbon -passout pass:wso2carbon
295+
```
296+
297+
### Step 7e: Import the CA Certificate into the Truststore
298+
299+
To ensure that WSO2 Identity Server can trust the CA for TLS communication, you need to add the CA certificate to the client truststore. You can either use the truststore provided in the WSO2 product distribution (`client-truststore.p12`) or create your own. This allows WSO2 IS to validate certificates issued by the CA, including its own TLS certificate.
300+
301+
```shell
302+
keytool -importcert \
303+
-alias wso2carbon \
304+
-file wso2carbon-ca.crt \
305+
-keystore client-truststore.p12 \
306+
-storetype PKCS12 \
307+
-storepass wso2carbon \
308+
-noprompt
309+
```
310+
311+
### Step 7f: Create Kubernetes Resources
312+
313+
Deploy the generated TLS Keystore and CA Certificate into the Kubernetes namespace.
314+
315+
**I. Create TLS Keystore Secret**
316+
317+
This secret contains the PKCS12 keystore used by the WSO2 Identity Server pods to secure their TLS communication.
318+
319+
```shell
320+
kubectl create secret generic keystores \
321+
--from-file=wso2carbon.p12 \
322+
--from-file=client-truststore.p12 \
323+
-n $NAMESPACE
324+
```
325+
326+
**II. Create CA Bundle ConfigMap**
327+
328+
This ConfigMap contains the Root CA certificate. Envoy Gateway uses this to verify the identity of the WSO2 IS pods during the TLS handshake.
329+
330+
```shell
331+
kubectl create configmap wso2-ca-bundle \
332+
--from-file=ca.crt=wso2carbon-ca.crt \
333+
-n $NAMESPACE
334+
```
335+
336+
## Step 8: Access {{product_name}}
203337

204338
Once everything is set up, you can access WSO2 Identity Server using the following URLs:
205339

@@ -208,4 +342,4 @@ Once everything is set up, you can access WSO2 Identity Server using the followi
208342

209343
Congratulations! You have successfully deployed WSO2 Identity Server on Kubernetes using Helm.
210344

211-
If you are deploying {{product_name}} on Azure Kubernetes Service (AKS) and require an advanced set up, refer to the relevant section in the [documentation](https://github.com/wso2/kubernetes-is/blob/master/README.md#advance-setup){:target = "_blank"}.
345+
If you are deploying {{product_name}} on Azure Kubernetes Service (AKS) and require an advanced setup, refer to the relevant section in the [documentation](https://github.com/wso2/kubernetes-is/blob/master/README.md#advance-setup){:target = "_blank"}.

0 commit comments

Comments
 (0)