Skip to content

Commit

Permalink
Merge pull request #372 from intelops/mtls-readme
Browse files Browse the repository at this point in the history
mTLS-readme added with configuration steps
  • Loading branch information
jebjohns authored May 20, 2024
2 parents c212004 + 4418c43 commit e2b2ab7
Show file tree
Hide file tree
Showing 2 changed files with 151 additions and 0 deletions.
18 changes: 18 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -223,6 +223,24 @@ kubectl --namespace kubviz port-forward $POD_NAME 3000

3. Access "localhost:3000" in your web browser, where you'll be prompted to enter your credentials. Utilize the username "admin" and the password obtained from step 1 to proceed.

#### mTLS - mutual TLS Feature

Mutual TLS (mTLS) is an extension of standard Transport Layer Security (TLS) that enhances security by requiring both the client and server to authenticate and verify each other's identities during the SSL/TLS handshake process. This mutual authentication helps ensure that both parties are who they claim to be, providing a higher level of security for sensitive data exchanges.

In our kubviz setup, we use mTLS for secure communication with the NATS server. Both the agent and the client connect to the NATS server using mTLS. The agent sends data to the NATS server securely, and the client also uses mTLS to receive data from the NATS server.

#### Why Use mTLS?

- **Enhanced Security:** mTLS ensures that both the client and server are authenticated, mitigating the risk of man-in-the-middle attacks.

- **Data Integrity:** By verifying identities, mTLS ensures that data is exchanged between trusted entities only.

- **Regulatory Compliance:** For many industries, mTLS is a requirement for compliance with regulations that mandate secure communication.

#### Configuring mTLS

To enable mTLS in your application for agent-to-NATS communication, [follow these steps:](docs/CONFIGURATION_MTLS.md)

#### TTL - Time-To-Live Feature

We've implemented a Time-To-Live (TTL) feature to streamline the management of data within your ClickHouse tables. With TTL, historical data can be automatically relocated to alternative storage or purged to optimize storage space. This feature is particularly valuable for scenarios like time-series data or logs where older data gradually loses its relevance over time.
Expand Down
133 changes: 133 additions & 0 deletions docs/CONFIGURATION_MTLS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,133 @@
# Configuring mTLS: Guidelines and Instructions

**Step-1: Create a ca-config.cnf file**

```$xslt
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
x509_extensions = v3_ca
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = US
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = New York
localityName = Locality Name (eg, city)
localityName_default = Albany
organizationName = Organization Name (eg, company)
organizationName_default = Kubviz
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
[ req_ext ]
subjectAltName = @alt_names
[ v3_ca ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kubviz-client-nats
DNS.2 = kubviz-client
DNS.3 = kubviz-agent
```

**Step-2: Create ca-cert.pem**

```bash
openssl genrsa -out ca-key.pem 4096
```

```bash
openssl req -new -x509 -days 365 -key ca-key.pem -out ca-cert.pem -subj "/C=US/ST=New York/L=Albany/O=Kubviz/CN=KubvizCA"
```

**Step-3: Create the Server Certificate**

```bash
openssl genrsa -out server-key.pem 4096
```

```bash
openssl req -new -key server-key.pem -out server-csr.pem -subj "/C=US/ST=New York/L=Albany/O=Kubviz/CN=kubviz-client-nats" -config ca-config.cnf -extensions req_ext
```

```bash
openssl x509 -req -days 365 -in server-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem -extfile ca-config.cnf -extensions v3_ca
```

**Step-4: Create the Client Certificate**

```bash
openssl genrsa -out client-key.pem 4096
```

```bash
openssl req -new -key client-key.pem -out client-csr.pem -subj "/C=US/ST=New York/L=Albany/O=Kubviz/CN=kubviz-client" -config ca-congig.cnf -extensions req_ext
```

```bash
openssl x509 -req -days 365 -in client-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial 02 -out client-cert.pem -extfile ca-config.cnf -extensions v3_ca
```

**step-5: Create the agent certificate**

```bash
openssl genrsa -out agent-key.pem 4096
```

```bash
openssl req -new -key agent-key.pem -out agent-csr.pem -subj "/C=US/ST=New York/L=Albany/O=Kubviz/CN=kubviz-agent" -config ca-config.cnf -extensions req_ext
```

```bash
openssl x509 -req -days 365 -in agent-csr.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial 02 -out agent-cert.pem -extfile ca-config.cnf -extensions v3_ca
```
**step-6: Create secrets**

```bash
kubectl create secret generic kubviz-client-ca-cert --from-file=client-cert.pem --from-file=client-key.pem --from-file=ca-cert.pem -n kubviz
```

```bash
kubectl create secret generic kubviz-agent-ca-cert --from-file=agent-cert.pem --from-file=agent-key.pem --from-file=ca-cert.pem -n kubviz
```

```bash
kubectl create secret generic kubviz-server-ca-cert --from-file=server-cert.pem --from-file=server-key.pem --from-file=ca-cert.pem -n kubviz
```

#### if you want to enable mtls add the secret name in client/values.yaml also mtls.enabled: true

**Step-7: Add the secret name in client/value.yaml**

Below is the nats configuration

```yaml
tls:
secret:
name: kubviz-server-ca-cert
ca: "ca-cert.pem"
cert: "server-cert.pem"
key: "server-key.pem"
verify: true
verify_and_map: true
...
```

**Step-8: Add the secret name in client/value.yaml**

```yaml
mtls:
enabled: true
secret:
name: kubviz-client-ca-cert
...
```

**Step-9: Add the secret name in agent/value.yaml**

```yaml
mtls:
enabled: true
secret:
name: kubviz-agent-ca-cert
...
```

0 comments on commit e2b2ab7

Please sign in to comment.