Тщательно изучите серию статей etcd (4): безопасность etcd

Микросервисы Архитектура

0 Обзор альбома

etcd является важным базовым компонентом облачной архитектуры, которая инкубируется и размещается CNCF. etcd можно использовать не только для регистрации и обнаружения сервисов в микросервисах и кластерах Kubernetes, но и как промежуточное ПО для хранения ключей и значений.

"Понимание статей серии etcd" познакомит с etcd с точки зрения базовой функциональной практики etcd, интерфейса API, принципа реализации, анализа исходного кода и опыта преодоления ям в реализации. Ожидается, что будет около 20 статей, автор будет обновлять каждую неделю, прошу обратить внимание.

1 безопасность

существуетпредыдущий постПосле введения в эксплуатацию и обслуживание развертывания кластера etcd в этой статье основное внимание будет уделено безопасному обмену данными в etcd. etcd поддерживает зашифрованную связь по протоколу TLS. Каналы TLS можно использовать для зашифрованной внутренней связи кластера между одноранговыми узлами и зашифрованным клиентским трафиком. В этой статье приведен пример настройки кластера с одноранговой сетью и протоколом TLS на стороне клиента.

2 TLS и SSL

Безопасность связи в Интернете основана на протоколе SSL/TLS. Связь HTTP без SSL/TLS является незашифрованной связью. Распространение всей информации в виде открытого текста сопряжено с тремя основными рисками:

  • Подслушивание: Третьи стороны могут узнать содержание сообщений.
  • Фальсификация: Третьи стороны могут изменять содержание сообщений.
  • Притворство: третья сторона может выдавать себя за другое лицо, чтобы участвовать в общении.

Протокол SSL/TLS предназначен для устранения этих трех рисков с целью достижения:

  • Вся информация передается в зашифрованном виде и не может быть перехвачена третьими лицами.
  • С механизмом проверки, как только он будет подделан, обе стороны в общении сразу обнаружат его.
  • Оснащен сертификатом удостоверения личности для предотвращения олицетворения личности.

Ниже приводится подробное введение в связанные концепции SSL и TLS:

  • SSL (Secure Socket Layer): разработан компанией Netscape для обеспечения безопасности передачи данных в Интернете с использованием технологии шифрования данных (Encryption), чтобы гарантировать, что данные не будут перехвачены в процессе передачи по сети. В настоящее время общим стандартом является 40-битный стандарт безопасности, а Соединенные Штаты ввели более высокий стандарт безопасности — 128-битный, но ему запрещено покидать страну. Пока браузер IE или Netscape версии 3.0 и выше поддерживает SSL.
  • Безопасность транспортного уровня (TLS) используется для обеспечения конфиденциальности и целостности данных между двумя взаимодействующими приложениями. Протокол состоит из двух уровней: TLS Record и TLS Handshake. Нижний уровень — это протокол записи TLS, который находится поверх некоторого надежного транспортного протокола, такого как TCP.

Для обеспечения доступа к зашифрованному протоколу HTTPS и обеспечения безопасности данных требуется сертификат SSL.TLS — это имя протокола безопасности транспортного уровня SSL и HTTPS.

3 Практикуйте шифрование TLS

Для практики мы установим некоторые полезные инструменты командной строки, в том числе cfssl, cfssljson.

cfssl — это инструмент CloudFlare PKI/TLS. Это и инструмент командной строки, и сервер HTTP API для подписи, проверки и связывания сертификатов TLS, и для сборки среды требуется Go 1.12+.

Программа cfssljson, которая получает вывод JSON от cfssl и записывает сертификат, ключ, CSR и пакет в указанное место.

Конфигурация среды

HostName ip Порт взаимодействия с клиентом одноранговый коммуникационный порт
infra0 192.168.202.128 2379 2380
infra1 192.168.202.129 2379 2380
infra2 192.168.202.130 2379 2380

3.1 Установите cfssl

$ ls ~/Downloads/cfssl
cfssl-certinfo_1.4.1_linux_amd64 cfssl_1.4.1_linux_amd64          cfssljson_1.4.1_linux_amd64

chmod +x cfssl_1.4.1_linux_amd64 cfssljson_1.4.1_linux_amd64 cfssl-certinfo_1.4.1_linux_amd64

mv cfssl_1.4.1_linux_amd64 /usr/local/bin/cfssl
mv cfssljson_1.4.1_linux_amd64 /usr/local/bin/cfssljson
mv cfssl-certinfo_1.4.1_linux_amd64 /usr/bin/cfssl-certinfo

После завершения установки просмотрите результаты информации о версии:

$ cfssl version

Version: 1.4.1
Runtime: go1.12.12

3.2 Настройте ЦС и создайте сертификат TLS

Мы будем использовать инструмент CloudFlare PKI cfssl для настройки инфраструктуры PKI, а затем использовать его для создания центра сертификации (CA) и сертификатов TLS для etcd.

Сначала создайте каталог конфигурации ssl:

mkdir /opt/etcd/{bin,cfg,ssl} -p
cd /opt/etcd/ssl/

Конфигурация etcd CA:

cat << EOF | tee ca-config.json
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "etcd": {
         "expiry": "87600h",
         "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ]
      }
    }
  }
}
EOF

etcd ca сертификат:

cat << EOF | tee ca-csr.json
{
    "CN": "etcd CA",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shanghai",
            "ST": "Shanghai"
        }
    ]
}
EOF

Сгенерируйте учетные данные CA и закрытый ключ:

$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca

2020/04/30 20:36:58 [INFO] generating a new CA key and certificate from CSR
2020/04/30 20:36:58 [INFO] generate received request
2020/04/30 20:36:58 [INFO] received CSR
2020/04/30 20:36:58 [INFO] generating key: rsa-2048
2020/04/30 20:36:58 [INFO] encoded CSR
2020/04/30 20:36:58 [INFO] signed certificate with serial number 252821789025044258332210471232130931231440888312

$ ls

ca-config.json  ca-csr.json  ca-key.pem  ca.csr  ca.pem

сертификат сервера etcd:

cat << EOF | tee server-csr.json
{
    "CN": "etcd",
    "hosts": [
    "192.168.202.128",
    "192.168.202.129",
    "192.168.202.130"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Beijing",
            "ST": "Beijing"
        }
    ]
}
EOF

Генерация сертификата сервера:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=etcd server-csr.json | cfssljson -bare server
2020/04/30 20:44:37 [INFO] generate received request
2020/04/30 20:44:37 [INFO] received CSR
2020/04/30 20:44:37 [INFO] generating key: rsa-2048
2020/04/30 20:44:37 [INFO] encoded CSR
2020/04/30 20:44:37 [INFO] signed certificate with serial number 73061688633166283265484923779818839258466531108

ls
ca-config.json  ca-csr.json  ca-key.pem  ca.csr  ca.pem  server-csr.json  server-key.pem  server.csr  server.pem

Запустите кластер etcd со следующей конфигурацией:

#etcd1 启动

$ /opt/etcd/bin/etcd --name etcd1 --initial-advertise-peer-urls https://192.168.202.128:2380 \
     --listen-peer-urls https://192.168.202.128:2380 \
     --listen-client-urls https://192.168.202.128:2379,https://127.0.0.1:2379 \
     --advertise-client-urls https://192.168.202.128:2379 \
     --initial-cluster-token etcd-cluster-1 \
     --initial-cluster etcd1=https://192.168.202.128:2380, etcd2=https://192.168.202.129:2380, etcd3=https://192.168.202.130:2380 \
     --initial-cluster-state new \
     --client-cert-auth --trusted-ca-file=/opt/etcd/ssl/ca.pem \
     --cert-file=/opt/etcd/ssl/server.pem --key-file=/opt/etcd/ssl/server-key.pem \
     --peer-client-cert-auth --peer-trusted-ca-file=/opt/etcd/ssl/ca.pem \
     --peer-cert-file=/opt/etcd/ssl/server.pem --peer-key-file=/opt/etcd/ssl/server-key.pem

#etcd2 启动
/opt/etcd/bin/etcd --name etcd2 --initial-advertise-peer-urls https://192.168.202.129:2380 \
      --listen-peer-urls https://192.168.202.129:2380 \
      --listen-client-urls https://192.168.202.129:2379,https://127.0.0.1:2379 \
      --advertise-client-urls https://192.168.202.129:2379 \
      --initial-cluster-token etcd-cluster-1 \
      --initial-cluster etcd1=https://192.168.202.128:2380, etcd2=https://192.168.202.129:2380, etcd3=https://192.168.202.130:2380 \
      --initial-cluster-state new \
      --client-cert-auth --trusted-ca-file=/opt/etcd/ssl/ca.pem \
      --cert-file=/opt/etcd/ssl/server.pem --key-file=/opt/etcd/ssl/server-key.pem \
      --peer-client-cert-auth --peer-trusted-ca-file=/opt/etcd/ssl/ca.pem \
      --peer-cert-file=/opt/etcd/ssl/server.pem --peer-key-file=/opt/etcd/ssl/server-key.pem
#etcd3 启动
/opt/etcd/bin/etcd --name etcd3 --initial-advertise-peer-urls https://192.168.202.130:2380 \
       --listen-peer-urls https://192.168.202.130:2380 \
       --listen-client-urls https://192.168.202.130:2379,https://127.0.0.1:2379 \
       --advertise-client-urls https://192.168.202.130:2379 \
       --initial-cluster-token etcd-cluster-1 \
       --initial-cluster etcd1=https://192.168.202.128:2380, etcd2=https://192.168.202.129:2380, etcd3=https://192.168.202.130:2380 \
       --initial-cluster-state new \
       --client-cert-auth --trusted-ca-file=/opt/etcd/ssl/ca.pem \
       --cert-file=/opt/etcd/ssl/server.pem --key-file=/opt/etcd/ssl/server-key.pem \
       --peer-client-cert-auth --peer-trusted-ca-file=/opt/etcd/ssl/ca.pem \
       --peer-cert-file=/opt/etcd/ssl/server.pem --peer-key-file=/opt/etcd/ssl/server-key.pem

Через консоли трех серверов мы можем узнать, что кластер успешно установлен, и мы проверим:

$ /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.202.128:2379,https://192.168.202.129:2379,https://192.168.202.130:2379"  endpoint health

# 输出如下：
https://192.168.202.129:2379 is healthy: successfully committed proposal: took = 9.492956ms
https://192.168.202.130:2379 is healthy: successfully committed proposal: took = 12.805109ms
https://192.168.202.128:2379 is healthy: successfully committed proposal: took = 13.036091ms

Проверьте работоспособность трех узлов,endpoint health, результат соответствует нашим ожиданиям. Во-вторых, просмотрите список членов кластера:

$ /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.202.128:2379,https://192.168.202.129:2379,https://192.168.202.130:2379" member list

# 输出如下：
48e15f7612b3de1, started, etcd2, https://192.168.202.129:2380, https://192.168.202.129:2379, false
6b57a3c3b8a54873, started, etcd3, https://192.168.202.130:2380, https://192.168.202.130:2379, false
c1ba2629c5bc62ac, started, etcd1, https://192.168.202.128:2380, https://192.168.202.128:2379, false

Выводит три члена, как мы и ожидали. Для кластера etcd, зашифрованного с помощью TLS, при работе необходимо добавить информацию, связанную с аутентификацией.Мы пытаемся записать, а затем прочитать:

$ /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.202.128:2379,https://192.168.202.129:2379,https://192.168.202.130:2379" put hello world

OK

$ /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.202.128:2379,https://192.168.202.129:2379,https://192.168.202.130:2379" get hello

hello
world

Запишите пару «ключ-значение» hello->wold, и при чтении консоль выводит значение ключа в обычном режиме. На данный момент мы успешно зашифровали связь etcd.

3.3 Автоматические сертификаты

Если кластеру требуется зашифрованная связь, но не аутентифицированные соединения, можно настроить etcd для автоматического создания ключей. При инициализации каждый участник создает свой собственный набор ключей на основе своего объявленного IP-адреса и хоста.

На каждой машине etcd будет запускаться со следующими флагами:

$ etcd --name etcd1 --initial-advertise-peer-urls https://192.168.202.128:2380 \
  --listen-peer-urls https://192.168.202.128:2380 \
  --listen-client-urls https://192.168.202.128:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://10.0.1.10:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster infra0=https://192.168.202.128:2380,infra1=https://192.168.202.129:2380,infra2=https://192.168.202.130:2380 \
  --initial-cluster-state new \
  --auto-tls \
  --peer-auto-tls

Уведомление, так как автоматическая выдача сертификата не аутентифицирует личность, прямой завиток вернет ошибку. нужно использовать завиток-kКоманда отключает проверку цепочки сертификатов.

4 Резюме

В этой статье основное внимание уделяется настройке аутентификации безопасности TLS кластера etcd.При передаче данных в виде открытого текста существуют риски подделки, подслушивания и олицетворения. Безопасность связи в Интернете основана на протоколе SSL/TLS. На основе инструмента cfssl он проверяет и привязывает сертификаты TLS для обеспечения связи между членами кластера etcd.

Подписывайтесь на свежие статьи, приглашаю обратить внимание на мой публичный номер

Рекомендуемое чтение

  1. Сравнение etcd с другими компонентами k-v, такими как Zookeeper и Consul
  2. Тщательно изучите серию статей etcd (1): первое знакомство с etcd
  3. Тщательно изучите серию статей etcd (2): различные позы установки etcd
  4. Тщательно изучите серию статей etcd (3): эксплуатация и обслуживание кластера etcd, развертывание.

Ссылаться на

etcd docs

Категории