Native Protocol encryption in YTsaurus

• Deploying a new cluster with encryption
• Enabling encryption on an existing cluster
• TLS parameters in the operator specification
• Automatic certificate rotation
• TLS operation modes

Deploying a new cluster with encryption

The easiest way to get started is to use the ready-made demo configuration with TLS enabled:

1. Install cert-manager (if it isn't already installed):

   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
   

2. Apply the cluster configuration with TLS:

   kubectl apply -f https://raw.githubusercontent.com/ytsaurus/ytsaurus-k8s-operator/main/config/samples/cluster_v1_tls.yaml
   

3. Check the deployment status:

   kubectl get ytsaurus -n <namespace>
   

   NAME       CLUSTERSTATE   UPDATESTATE   UPDATINGCOMPONENTS   BLOCKEDCOMPONENTS
   ytsaurus   Running        None
   

   This command shows the status of the YTsaurus cluster. The Running status means the cluster has started successfully and is operational. Empty UPDATINGCOMPONENTS and BLOCKEDCOMPONENTS fields indicate that all components are working normally.

   kubectl get certificates -n <namespace>
   

   NAME                   READY   SECRET                 AGE
   ytsaurus-ca            True    ytsaurus-ca-secret     42d
   ytsaurus-https-cert    True    ytsaurus-https-cert    42d
   ytsaurus-native-cert   True    ytsaurus-native-cert   42d
   ytsaurus-rpc-cert      True    ytsaurus-rpc-cert      42d
   

   This command lists the certificates managed by cert-manager. The READY: True status confirms that the certificates have been issued and are ready for use. The ytsaurus-native-cert certificate is used to encrypt internal bus traffic between components.

   kubectl get secrets -n <namespace> | grep -E "ytsaurus|tls|cert"
   

   ytsaurus-ca-secret      kubernetes.io/tls   3      41d
   ytsaurus-https-cert     kubernetes.io/tls   3      41d
   ytsaurus-native-cert    kubernetes.io/tls   3      41d
   ytsaurus-rpc-cert       kubernetes.io/tls   3      41d
   

   This command displays Kubernetes secrets that contain TLS certificates and keys.

   • Type kubernetes.io/tls indicates a TLS secret.

   • Value 3 in the DATA column means the secret includes three items:

     • tls.crt (certificate).
     • tls.key (private key).
     • ca.crt (CA certificate used for verification).

   kubectl describe ytsaurus <cluster-name> -n <namespace> | grep -A 5 "Native Transport"
   

   Native Transport:
     Tls Client Secret:
       Name:                          ytsaurus-native-cert
     Tls Insecure:                    true
     Tls Peer Alternative Host Name:  interconnect.ytsaurus-dev.svc.cluster.local
     Tls Required:                    true
     Tls Secret:
       Name:  ytsaurus-native-cert
   

   This command shows the encryption settings in the cluster configuration. The Tls Required: true parameter confirms that encryption is mandatory for internal connections.

   kubectl describe certificate <certificate-name> -n <namespace>
   

   Name:         ytsaurus-native-cert
   Namespace:    default
   Status:
     Conditions:
       Last Transition Time:  2026-01-30T07:45:50Z
       Message:               Certificate is up to date and has not expired
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Not After:               2026-04-30T07:45:50Z
     Not Before:              2026-01-30T07:45:50Z
     Renewal Time:            2026-03-31T07:45:50Z
   

   This command displays certificate details. The Not After (expiry) and Renewal Time fields confirm automatic certificate rotation via cert-manager.

   kubectl get secret <secret-name> -n <namespace> -o jsonpath='{.data.ca\.crt}' | base64 -d > /tmp/ca.crt
   kubectl exec -n ytsaurus hp-0 -- curl --cacert /tmp/ca.crt -k -v https://hp-0.http-proxies.ytsaurus.svc.cluster.local:443/api/v4/
   

   This command checks the TLS handshake when connecting to the cluster API from inside the cluster. The -v option enables verbose mode so you can see the full process of establishing a secure connection.

   Example output showing a successful TLS handshake

   * Connected to hp-0.http-proxies.ytsaurus.svc.cluster.local (10.1.1.93) port 443
   * ALPN, offering h2
   * ALPN, offering http/1.1
   * TLSv1.3 (OUT), TLS handshake, Client hello (1):
   } [512 bytes data]
   * TLSv1.3 (IN), TLS handshake, Server hello (2):
   { [93 bytes data]
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   { [926 bytes data]
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   { [300 bytes data]
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   { [4 bytes data]
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   } [37 bytes data]
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   } [1 bytes data]
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   } [16 bytes data]
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   { [16 bytes data]
   * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
   * ALPN, server did not agree on a protocol
   * Server certificate:
   *  subject: [NONE]
   *  start date: Jan 30 07:45:50 2026 GMT
   *  expire date: Apr 30 07:45:50 2026 GMT
   *  issuer: O=ytsaurus CA; CN=ytsaurus-ca
   *  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
   > GET /api/v4/ HTTP/1.1
   > Host: hp-0.http-proxies.ytsaurus.svc.cluster.local
   > User-Agent: curl/7.68.0
   > Accept: */*
   < HTTP/1.1 200 OK
   < Content-Length: 18118
   < X-YT-Trace-Id: b430ab8e-c4e8ab91-fcb54bb1-3c53ef11
   < Cache-Control: no-store
   < X-YT-Request-Id: 40981ad3-5ad47b6c-74c2640f-20856da1
   < X-YT-Proxy: hp-0.http-proxies.ytsaurus.svc.cluster.local
   < Content-Type: application/json
   

   The output shows that every stage of the TLS handshake completed successfully: Client hello → Server hello → Certificate → Key exchange → Finished. The connection is established using the TLSv1.2 protocol with the ECDHE-RSA-AES256-GCM-SHA384 cipher. The certificate is issued by ytsaurus CA and is valid until the specified date. The HTTP/1.1 200 OK response confirms that the request was successfully executed over the secure connection.

   Key points in the output:

   • All TLS handshake stages completed successfully (Client hello → Server hello → Certificate → Key exchange → Finished).
   • The connection was established using the TLSv1.2 protocol.
   • The connection uses a modern cipher: ECDHE-RSA-AES256-GCM-SHA384.
   • The certificate is issued by ytsaurus CA and valid until Apr 30 07:45:50 2026 GMT.
   • The YTsaurus HTTP proxy (X-YT-Proxy: hp-0.http-proxies.ytsaurus.svc.cluster.local) successfully processes the request over the secure connection.
   • The HTTP/1.1 200 OK response confirms successful request execution over TLS.

This configuration automatically creates a self-signed CA, issues certificates, and configures components to use encryption with mutual authentication (mTLS).

Configuring encryption on an existing cluster

To enable encryption on a running cluster, add the following parameters to the YTsaurus specification:

spec:
  # CA certificate for verification
  caBundle:
    kind: Secret
    name: ytsaurus-ca-secret
    key: tls.crt

  # TLS settings for internal transport
  nativeTransport:
    tlsSecret:
      name: ytsaurus-native-cert
    tlsRequired: true
    tlsInsecure: true
    tlsPeerAlternativeHostName: "interconnect.ytsaurus-dev.svc.cluster.local"

TLS parameters in the operator specification

Automatic certificate rotation

When using cert-manager, rotation happens automatically:

• Cert-manager monitors certificate expiration dates.
• A new certificate is issued when the expiration date approaches.
• The secret is updated without restarting any pods.
• Components begin using the new certificate for new connections.

How automatic rotation works:

• When the current certificate is about to expire, cert-manager automatically issues a new one.

• The new certificate and key are updated in the Kubernetes Secret mounted inside the container.

• The certificate file mounted inside the server container is refreshed automatically without requiring a pod restart.

• Each server periodically reloads the certificate:

  • At the bus layer — for every new connection.
  • Existing connections remain active with the old certificate.
  • New connections use the updated certificate.

TLS operation modes

Different TLS operation modes are formed based on the values of tlsRequired and tlsInsecure:

Legend:

• EO – Encryption Optional
• ER – Encryption Required
• VN – Verification None
• VF – Verification Full