You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: en/includes/deploy/deploy-is-on-kubernetes.md
+134-2Lines changed: 134 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -33,6 +33,18 @@ Make sure you have the following before starting this guide.
33
33
34
34
- A Kubernetes [Ingress-Nginx Controller](https://kubernetes.github.io/ingress-nginx/deploy/){:target="_blank"}.
35
35
36
+
- Envoy Gateway (Required for the Kubernetes Gateway API pattern). If choosing this option, 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.
Define environment variables for the Kubernetes namespace and Helm release name.
@@ -199,7 +211,127 @@ If your hostname is backed by a DNS service, create a DNS record that maps the h
199
211
<EXTERNAL-IP> wso2is.com
200
212
```
201
213
202
-
## Step 7: Access {{product_name}}
214
+
## Step 7: (Optional) Configure Backend TLS for Envoy Gateway
215
+
216
+
!!! note
217
+
This step is only required if you are using Envoy Gateway.
218
+
219
+
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.
220
+
221
+
You must provide a Kubernetes ConfigMap containing the CA certificate that signed the WSO2 IS TLS certificate.
222
+
223
+
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.
224
+
225
+
!!! note
226
+
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.
227
+
228
+
### Step 7a: Generate a Self-Signed Certificate Authority (CA)
229
+
230
+
First, create a private key and a self-signed root certificate to act as your internal CA.
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`.
245
+
246
+
```
247
+
[req]
248
+
distinguished_name = req_distinguished_name
249
+
req_extensions = v3_req
250
+
prompt = no
251
+
252
+
[req_distinguished_name]
253
+
CN = localhost
254
+
255
+
[v3_req]
256
+
keyUsage = digitalSignature, keyEncipherment
257
+
extendedKeyUsage = serverAuth
258
+
subjectAltName = @alt_names
259
+
260
+
[alt_names]
261
+
DNS.1 = localhost
262
+
```
263
+
264
+
### Step 7c: Generate and Sign the WSO2 IS Certificate
265
+
266
+
Generate a new private key forthe WSO2 IS Keystore and sign the request using the CA createdin Step 7a.
### Step 7e: Import the CA Certificate into the Truststore
296
+
297
+
To ensure that WSO2 Identity Server can trust the CA forTLS communication, you need to add the CA certificate to the client truststore. You can either use the truststore providedin 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.
298
+
299
+
```shell
300
+
keytool -importcert \
301
+
-alias wso2carbon \
302
+
-file wso2carbon-ca.crt \
303
+
-keystore client-truststore.p12 \
304
+
-storetype PKCS12 \
305
+
-storepass wso2carbon \
306
+
-noprompt
307
+
```
308
+
309
+
### Step 7f: Create Kubernetes Resources
310
+
311
+
Deploy the generated TLS Keystore and CA Certificate into the Kubernetes namespace.
312
+
313
+
**I. Create TLS Keystore Secret**
314
+
315
+
This secret contains the PKCS12 keystore used by the WSO2 Identity Server pods to secure their TLS communication.
316
+
317
+
```shell
318
+
kubectl create secret generic keystores \
319
+
--from-file=wso2carbon.p12 \
320
+
--from-file=client-truststore.p12 \
321
+
-n $NAMESPACE
322
+
```
323
+
324
+
**II. Create CA Bundle ConfigMap**
325
+
326
+
This ConfigMap contains the Root CA certificate. Envoy Gateway uses this to verify the identity of the WSO2 IS pods during the TLS handshake.
327
+
328
+
```shell
329
+
kubectl create configmap wso2-ca-bundle \
330
+
--from-file=ca.crt=wso2carbon-ca.crt \
331
+
-n $NAMESPACE
332
+
```
333
+
334
+
## Step 8: Access {{product_name}}
203
335
204
336
Once everything is set up, you can access WSO2 Identity Server using the following URLs:
205
337
@@ -208,4 +340,4 @@ Once everything is set up, you can access WSO2 Identity Server using the followi
208
340
209
341
Congratulations! You have successfully deployed WSO2 Identity Server on Kubernetes using Helm.
210
342
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"}.
343
+
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"}.
0 commit comments