Шифрование в нативном протоколе YTsaurus

• Развёртывание нового кластера с шифрованием
• Включение шифрования на существующем кластере
• Параметры TLS в спецификации оператора
• Автоматическая ротация сертификатов
• Режимы работы TLS

Развёртывание нового кластера с шифрованием

Самый простой способ — использовать готовый демо-пример конфигурации с включенным TLS:

1. Установите cert-manager (если еще не установлен):

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

2. Примените конфигурацию кластера с TLS:

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

3. Проверьте статус развёртывания:

   kubectl get ytsaurus -n <namespace>
   

   NAME       CLUSTERSTATE   UPDATESTATE   UPDATINGCOMPONENTS   BLOCKEDCOMPONENTS
   ytsaurus   Running        None
   

   Команда показывает статус кластера YTsaurus. Статус Running означает, что кластер успешно запущен и работает. Пустые поля UPDATINGCOMPONENTS и BLOCKEDCOMPONENTS указывают на нормальную работу всех компонентов.

   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
   

   Команда выводит список сертификатов, управляемых cert-manager. Статус READY: True подтверждает, что сертификаты успешно выпущены и готовы к использованию. Сертификат ytsaurus-native-cert используется для шифрования внутреннего bus-трафика между компонентами.

   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
   

   Команда показывает секреты Kubernetes с TLS-сертификатами и ключами.

   • Тип kubernetes.io/tls указывает на TLS-секрет;

   • Число 3 в колонке DATA означает три компонента:

     • tls.crt (сертификат);
     • tls.key (приватный ключ);
     • ca.crt (CA сертификат для проверки).

   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
   

   Команда показывает настройки шифрования в конфигурации кластера. Параметр Tls Required: true подтверждает обязательное использование шифрования для внутренних соединений.

   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
   

   Команда показывает детали сертификата. Поля Not After (истечение) и Renewal Time (время обновления) подтверждают автоматическую ротацию сертификатов через 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/
   

   Команда проверяет TLS-handshake при подключении к API кластера изнутри кластера. Опция -v включает verbose-режим для просмотра процесса установки защищённого соединения.

   Пример вывода, показывающий успешный 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
   

   Вывод показывает успешное выполнение всех этапов TLS-handshake: Client hello → Server hello → Certificate → Key exchange → Finished. Соединение установлено по протоколу TLSv1.2 с использованием шифра ECDHE-RSA-AES256-GCM-SHA384. Сертификат выдан ytsaurus CA и действителен до указанной даты. Статус ответа HTTP/1.1 200 OK подтверждает успешное выполнение запроса через защищённое соединение.

   Ключевые моменты в выводе:

   • Успешное выполнение всех этапов TLS-handshake (Client hello → Server hello → Certificate → Key exchange → Finished)
   • Установлено соединение по протоколу TLSv1.2
   • Используется современный шифр ECDHE-RSA-AES256-GCM-SHA384
   • Сертификат выдан ytsaurus CA и действителен до Apr 30 07:45:50 2026 GMT
   • HTTP-прокси YTsaurus (X-YT-Proxy: hp-0.http-proxies.ytsaurus.svc.cluster.local) успешно обрабатывает запрос через защищённое соединение
   • Статус ответа HTTP/1.1 200 OK подтверждает успешное выполнение запроса через TLS

Эта конфигурация автоматически создает самоподписанный CA, выпускает сертификаты и настраивает компоненты для работы шифрования с взаимной аутентификаций (mTLS).

Включение шифрования на существующем кластере

Для включения шифрования на работающем кластере добавьте в спецификацию YTsaurus следующие параметры:

spec:
  # CA сертификат для проверки
  caBundle:
    kind: Secret
    name: ytsaurus-ca-secret
    key: tls.crt

  # Настройки TLS для внутреннего транспорта
  nativeTransport:
    tlsSecret:
      name: ytsaurus-native-cert
    tlsRequired: true
    tlsInsecure: true
    tlsPeerAlternativeHostName: "interconnect.ytsaurus-dev.svc.cluster.local"

Параметры TLS в спецификации оператора

Автоматическая ротация сертификатов

При использовании cert-manager ротация происходит автоматически:

• Cert-manager отслеживает срок действия сертификатов.
• При приближении истечения срока выпускается новый сертификат.
• Секрет обновляется без перезапуска подов.
• Компоненты используют новый сертификат для новых соединений.

Как работает автоматическая ротация:

• Когда срок действия текущего сертификата истекает, cert-manager автоматически выпускает новый сертификат.

• Новый сертификат и ключ обновляются в Kubernetes Secret, который смонтирован в контейнер.

• Файл сертификата, смонтированный в контейнер сервера, автоматически обновляется без перезапуска пода.

• Каждый сервер периодически перечитывает сертификат:

  • на уровне BUS — при каждом новом соединении;
  • существующие соединения продолжают работать со старым сертификатом;
  • новые соединения используют обновлённый сертификат.

Режимы работы TLS

В зависимости от значений tlsRequired и tlsInsecure формируются разные режимы работы TLS:

Расшифровка:

• EO – Encryption Optional (шифрование опционально)
• ER – Encryption Required (шифрование обязательно)
• VN – Verification None (проверка сертификатов отключена)
• VF – Verification Full (полная проверка сертификатов)