|
1 | 1 | ---
|
2 |
| -title: kmeshctl secret |
3 |
| -sidebar_position: 6 |
| 2 | +draft: true |
| 3 | +linktitle: Use IPsec in Kmesh cluster |
| 4 | +menu: |
| 5 | + docs: |
| 6 | + parent: user guide |
| 7 | + weight: 21 |
| 8 | +title: Use IPsec in Kmesh cluster |
| 9 | +toc: true |
| 10 | +type: docs |
| 11 | + |
4 | 12 | ---
|
5 | 13 |
|
6 |
| -Use secrets to generate secret configuration data for IPsec |
| 14 | +### Use IPsec in Kmesh cluster |
7 | 15 |
|
8 |
| -```bash |
9 |
| -kmeshctl secret [flags] |
| 16 | +IPsec is a mature and widely used encryption method for inter-node communication. This document explains how to enable IPsec to encrypt communication data between Kmesh-managed nodes. |
| 17 | + |
| 18 | +### How to enable IPsec in Kmesh |
| 19 | + |
| 20 | +#### Step 1: Generate an IPsec pre-shared key for Kmesh before starting Kmesh. Currently, only the rfc4106 (gcm(AES)) algorithm is supported. The key must be 36 bytes (32 bytes for the algorithm key and 4 bytes for the salt), provided as a 72-character hexadecimal string |
| 21 | + |
| 22 | +``` bash |
| 23 | +kmeshctl secret --key=<aead key> |
10 | 24 | ```
|
11 | 25 |
|
12 |
| -### Examples |
| 26 | +If you want to randomly generate a key, you can use the following command |
13 | 27 |
|
14 | 28 | ```bash
|
15 |
| -# Use secrets to generate secret configuration data for IPsec: |
16 |
| - Use --key (or -k) with the AEAD algorithm rfc4106(gcm(aes)); the key must be 36 characters long (32 for key and 4 for salt). |
17 |
| - A hexadecimal dump is required when the key is entered. |
18 |
| - e.g.: kmeshctl secret --key=$(dd if=/dev/urandom count=36 bs=1 2>/dev/null | xxd -p -c 64) |
19 |
| - e.g.: kmeshctl secret -k=$(echo -n "{36-character user-defined key here}" | xxd -p -c 64) |
| 29 | +kmeshctl secret --key=$(dd if=/dev/urandom count=36 bs=1 2>/dev/null | xxd -p -c 64) |
20 | 30 | ```
|
21 | 31 |
|
22 |
| -### Options |
| 32 | +If you want to use a custom key, you can use the following command |
23 | 33 |
|
24 |
| -```bash |
25 |
| - -h, --help help for secret |
26 |
| - -k, --key string key of the encryption |
| 34 | +``` bash |
| 35 | +kmeshctl secret --key=$(echo -n "{36-bytes user-defined key here}" | xxd -p -c 64) |
| 36 | +``` |
| 37 | + |
| 38 | +#### Step 2: Add the parameter --enable-ipsec=true to the Kmesh yaml |
| 39 | + |
| 40 | +```plaintext |
| 41 | +kmesh.yaml |
| 42 | +... |
| 43 | +args: |
| 44 | +[ |
| 45 | + "./start_kmesh.sh --mode=dual-engine --enable-bypass=false --enable-ipsec=true", |
| 46 | +] |
| 47 | +... |
| 48 | +``` |
| 49 | + |
| 50 | +#### Step 3: Place pods or namespace under the management of Kmesh |
| 51 | + |
| 52 | +Only when both communicating pods are managed by Kmesh, will they enter the encryption process. |
| 53 | + |
| 54 | +``` bash |
| 55 | +kubectl label namespace default istio.io/dataplane-mode=Kmesh |
| 56 | +``` |
| 57 | + |
| 58 | +#### Step 4: Test whether the data packet has been encrypted |
| 59 | + |
| 60 | +Use tcpdump on nodes to capture packets and check if IPsec has been used during data communication between nodes (determined by ESP packets) |
| 61 | + |
| 62 | +```plaintext |
| 63 | +tcpdump -i any |grep ESP |
| 64 | +... |
| 65 | +14:19:24.143654 ? Out IP master > node1: ESP(spi=0x00000001,seq=0x3da88), length 80 |
| 66 | +14:19:24.143690 ? Out IP master > node1: ESP(spi=0x00000001,seq=0x3da89), length 80 |
| 67 | +14:19:24.143707 ? In IP node1 > master: ESP(spi=0x00000001,seq=0x3c037), length 80 |
| 68 | +14:19:24.143738 ? In IP node1 > master: ESP(spi=0x00000001,seq=0x3c038), length 172 |
| 69 | +... |
| 70 | +``` |
| 71 | + |
| 72 | +#### Step 5: Replace pre shared key |
| 73 | + |
| 74 | +After a period of time, the pre-shared key of the cluster can be changed. After changing the pre-shared key, the ESP SPI number of the IPsec used for communication between nodes will be increased by 1 compared to the previous version. This can be observed again through using tcpdump. The initial IPSec SPI version number is 1 |
| 75 | + |
| 76 | +```plaintext |
| 77 | +root@master:~/kmesh# tcpdump -i any |grep ESP |
| 78 | +... |
| 79 | +14:26:33.782665 ? Out IP master > node1: ESP(spi=0x00000002,seq=0x1aaa1), length 80 |
| 80 | +14:26:33.782666 ? Out IP master > node1: ESP(spi=0x00000002,seq=0x1aaa2), length 80 |
| 81 | +14:26:33.782667 ? In IP node1 > master: ESP(spi=0x00000002,seq=0x183d2), length 80 |
| 82 | +14:26:33.782667 ? In IP node1 > master: ESP(spi=0x00000002,seq=0x183d3), length 80 |
| 83 | +... |
27 | 84 | ```
|
| 85 | + |
| 86 | +### Note |
| 87 | + |
| 88 | +1. IPsec encryption uses mark `0xe0` and `0xd0` as markers for IPsec encryption and decryption. Please ensure that no conflicting Mark is used on the host network, otherwise unknown behavior may occur |
| 89 | + |
| 90 | +2. Please ensure that `address MASQ` is not used on packets encrypted with IPsec. After address MASQ, IPsec cannot accurately match encryption and decryption rules, which can result in packet loss |
0 commit comments