TOC

Как обезопасить свой кластер CoreOS с помощью правил TLS / SSL и брандмауэра

Вступление

Если вы планируете запускать кластер CoreOS в сетевой среде вне вашего контроля, например, в общем центре обработки данных или через общедоступный Интернет, вы, возможно, заметили, что `+ etcd + 'связывается с помощью незашифрованных HTTP-запросов. Можно снизить риски такого поведения, настроив брандмауэр IPTables на каждом узле в кластере, но в идеальном решении в идеале следует использовать зашифрованный транспортный уровень.

К счастью, + etcd + поддерживает одноранговые соединения TLS / SSL, так что каждый член кластера проходит проверку подлинности и все соединения шифруются. В этом руководстве мы начнем с предоставления простого кластера с тремя участниками, а затем настроим конечные точки HTTPS и базовый брандмауэр на каждой машине.

Предпосылки

Это руководство в значительной степени опирается на концепции, обсуждаемые в this введение в компоненты системы CoreOS и https: //www.digitalocean. com / community / tutorials / how-to-setup-a-coreos-cluster-on-digitalocean [это руководство по настройке кластера CoreOS в DigitalOcean].

Вы должны быть знакомы с основами файлов + etcd,` + fleetctl`, + cloud-config и генерацией URL-адреса обнаружения.

Для создания и доступа к компьютерам в вашем кластере вам понадобится открытый ключ SSH, связанный с вашей учетной записью DigitalOcean. Подробную информацию об использовании ключей SSH с DigitalOcean можно найти здесь: here.

Если вы хотите использовать API DigitalOcean для создания ваших машин с ОС CoreOS, перейдите по ссылке https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate- a-personal-access-token [это руководство] для получения информации о том, как создавать и использовать персональный токен доступа с разрешениями на запись. Использование API является необязательным, но может сэкономить ваше время в долгосрочной перспективе, особенно если вы планируете создавать более крупные кластеры.

Создать новый URL-адрес обнаружения

Извлеките новый URL-адрес обнаружения из discovery.etcd.io, либо перейдя по ссылке https://discovery.etcd.io/new?size=3 в своем браузере и скопировав отображаемый URL-адрес, либо воспользовавшись + curl + из терминала на ваш локальный компьютер:

curl -w "\n" "https://discovery.etcd.io/new?size=3"

Сохранить возвращенный URL; мы будем использовать его в нашем + cloud-config + в ближайшее время.

Написать файл конфигурации облака, включая конфигурацию HTTPS

Мы начнем с написания + cloud-config. + Cloud-config + будет предоставлен как * пользовательские данные * при инициализации каждого сервера, определяя важные детали конфигурации для кластера. Этот файл будет длинным, но не должен быть намного сложнее, чем версия в https://www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on- digitalocean [руководство по основным кластерам]. Мы явно сообщим + fleet + об использовании конечных точек HTTPS, включим службу + iptables-restore + для нашего брандмауэра и выпишем файлы конфигурации, сообщающие + etcd + и + fleet +, где найти SSL-сертификаты.

Откройте терминал на вашем локальном компьютере, убедитесь, что вы находитесь в своем домашнем каталоге, и используйте + nano + (или ваш любимый текстовый редактор), чтобы создать и открыть + ~ / cloud-config.yml +:

cd ~
nano cloud-config.yml

Вставьте следующее, затем измените ++ в разделе + etcd2 + на URL-адрес обнаружения, который вы указали в предыдущем разделе.

Вы также можете удалить раздел + iptables-restore +, если вы не хотите включать брандмауэр.

Будьте осторожны с отступами при вставке. + Cloud-config + написан на YAML, который чувствителен к пробелам. Смотрите комментарии в файле для получения информации о конкретных строках, а затем мы рассмотрим некоторые важные разделы более подробно.

~ / Облако config.yml

#cloud-config

coreos:
 etcd2:
   # generate a new token for each unique cluster from https://discovery.etcd.io/new:
   discovery:
   # multi-region deployments, multi-cloud deployments, and Droplets without
   # private networking need to use $public_ipv4:
   advertise-client-urls: https://$private_ipv4:2379,https://$private_ipv4:4001
   initial-advertise-peer-urls: https://$private_ipv4:2380
   # listen on the official ports 2379, 2380 and one legacy port 4001:
   listen-client-urls: https://0.0.0.0:2379,https://0.0.0.0:4001
   listen-peer-urls: https://$private_ipv4:2380
 fleet:
   # fleet defaults to plain HTTP - explicitly tell it to use HTTPS on port 4001:
   etcd_servers: https://$private_ipv4:4001
   public-ip: $private_ipv4   # used for fleetctl ssh command
 units:
   - name: etcd2.service
     command: start
   - name: fleet.service
     command: start




write_files:
 # tell etcd2 and fleet where our certificates are going to live:
 - path: /run/systemd/system/etcd2.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client environment variables
     Environment=ETCD_CA_FILE=/home/core/ca.pem
     Environment=ETCD_CERT_FILE=/home/core/coreos.pem
     Environment=ETCD_KEY_FILE=/home/core/coreos-key.pem
     # peer environment variables
     Environment=ETCD_PEER_CA_FILE=/home/core/ca.pem
     Environment=ETCD_PEER_CERT_FILE=/home/core/coreos.pem
     Environment=ETCD_PEER_KEY_FILE=/home/core/coreos-key.pem
 - path: /run/systemd/system/fleet.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client auth certs
     Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem
     Environment=FLEET_ETCD_CERTFILE=/home/core/coreos.pem
     Environment=FLEET_ETCD_KEYFILE=/home/core/coreos-key.pem

В качестве необязательного шага вы можете вставить свой + cloud-config + в the официальный CoreOS Cloud Config Validator и нажать * Validate Cloud-Config *.

Сохраните файл и выйдите. В + nano + вы можете выполнить это с помощью * Ctrl-X * для выхода, * y * для подтверждения записи файла и * Enter * для подтверждения имени файла для сохранения.

Давайте посмотрим на несколько конкретных блоков из + cloud-init.yml +. Во-первых, значения + fleet +:

 fleet:
   # fleet defaults to plain HTTP - explicitly tell it to use HTTPS:
   etcd_servers: https://$private_ipv4:4001
   public-ip: $private_ipv4   # used for fleetctl ssh command

Обратите внимание, что для + etcd_servers + задан URL + https +. Для обычной операции HTTP это значение не нужно устанавливать. Однако без явной настройки HTTPS не будет работать. (+ $ private_ipv4 + - это переменная, понимаемая процессом инициализации CoreOS, а не та, которую вам нужно изменить.)

Далее мы переходим к блоку + write_files +. Значения разбиты на файловую систему + path,` + permissions` mask и + contents, которая содержит требуемое содержимое файла. Здесь мы указываем, что файлы модулей + systemd + для сервисов + etcd2 + и + fleet + должны устанавливать переменные среды, указывающие на сертификаты TLS / SSL, которые мы будем генерировать:

write_files:
 # tell etcd2 and fleet where our certificates are going to live:
 - path: /run/systemd/system/etcd2.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client environment variables
     Environment=ETCD_CA_FILE=/home/core/ca.pem
     ...
 - path: /run/systemd/system/fleet.service.d/30-certificates.conf
   permissions: 0644
   content: |
     [Service]
     # client auth certs
     Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem
     ...

Пока мы сообщаем сервисам, где искать файлы сертификатов, мы пока не можем сами предоставить файлы. Для этого нам необходимо знать частный IP-адрес каждого компьютера с ОС CoreOS, который будет доступен только после создания компьютеров.

Предоставление капель

Теперь, когда мы определили + cloud-config.yml +, мы будем использовать его для подготовки каждого члена кластера. В DigitalOcean есть два основных подхода: через веб-панель управления или вызовы API DigitalOcean с помощью cURL из командной строки.

Использование панели управления DigitalOcean

Создайте три новых капли CoreOS в одном регионе центра обработки данных. Обязательно проверяйте * Private Networking * и * Enable User Data * каждый раз.

  • * coreos-1 *

  • * coreos-2 *

  • * coreos-3 *

В поле * User Data * вставьте содержимое + cloud-config.yml + сверху, убедившись, что вы вставили URL-адрес обнаружения в поле + discovery + в верхней части файла.

Использование API DigitalOcean

В качестве альтернативного подхода, который может сохранить повторяющиеся вставки в поля, мы можем написать короткий Bash-скрипт, который использует + curl + для запроса новой капли из API DigitalOcean с помощью нашего + + cloud-config + и запускает ее один раз для каждой капли , Откройте новый файл с именем `+ makecoreos.sh + с помощью + nano + (или по своему выбору):

cd ~
nano makecoreos.sh

Вставьте и сохраните следующий скрипт, корректируя поля + region + и + size + по желанию для вашего кластера (значения по умолчанию + nyc3 + и + 512mb + подходят для демонстрационных целей, но вы можете захотеть другое капли региона или больше для реальных проектов):

~ / Makecoreos.sh

#!/usr/bin/env bash

# A basic Droplet create request.
curl -X POST "https://api.digitalocean.com/v2/droplets" \
    -d'{"name":"'"$1"'","region":"","size":"","private_networking":true,"image":"coreos-stable","user_data":
"'"$(cat ~/cloud-config.yml)"'",
        "ssh_keys":[ "'$DO_SSH_KEY_FINGERPRINT'" ]}' \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json"

Теперь давайте установим переменные среды + $ DO_SSH_KEY_FINGERPRINT + и + $ TOKEN + для отпечатка ключа SSH, связанного с вашей учетной записью DigitalOcean и вашим персональным токеном API, соответственно.

Для получения информации о получении Персонального токена доступа и использовании API обратитесь к this учебник.

Чтобы найти отпечаток ключа, связанного с вашей учетной записью, перейдите в раздел the * Security * настроек вашей учетной записи в разделе * SSH Keys *. Он будет иметь вид public key fingerprint, что-то вроде `+43: 51: 43: a1: b5: fc: 8b: b7: 0a: 3a : а9: б1: 0f: 66: 73: а8 + `.

Мы используем + export + здесь, чтобы дочерние процессы оболочки, такие как + makecoreos.sh +, могли получить доступ к переменным. Оба должны быть установлены в текущей оболочке каждый раз, когда используется скрипт, иначе вызов API завершится неудачно:

export DO_SSH_KEY_FINGERPRINT=""
export TOKEN=""

После того, как мы установили переменные среды для каждого из необходимых учетных данных, мы можем запустить сценарий для создания каждой желаемой капли. + makecoreos.sh + использует свой первый параметр для заполнения поля + name + в своем вызове API:

bash makecoreos.sh coreos-1
bash makecoreos.sh coreos-2
bash makecoreos.sh coreos-3

Вы должны увидеть выходные данные JSON с описанием каждой новой капли, и все три должны появиться в вашем списке капель на панели управления. Для завершения загрузки может потребоваться несколько секунд.

Войти в coreos-1

Независимо от того, использовали ли вы панель управления или API, теперь у вас должно быть три запущенных капли. Сейчас самое время отметить их общедоступные и частные IP-адреса, которые доступны, нажав на отдельную каплю на панели управления, а затем нажав ссылку * Настройки *. При создании сертификатов и настройке брандмауэра потребуется частный IP-адрес каждой капли.

Давайте проверим капельку. Убедитесь, что ваш ключ SSH добавлен к вашему локальному агенту SSH:

eval $(ssh-agent)
ssh-add

Найдите общедоступный IP-адрес * coreos-1 * на панели управления DigitalOcean и подключитесь с включенной переадресацией агента SSH:

ssh -A core@

При первом входе в систему любого члена кластера мы можем получить сообщение об ошибке от + systemd +:

OutputCoreOS stable (766.5.0)
Failed Units: 1
 iptables-restore.service

Это указывает на то, что брандмауэр еще не настроен. На данный момент безопасно игнорировать это сообщение. (Если вы решили не включать брандмауэр в вашем + cloud-config +, вы не увидите сообщение об ошибке. Вы всегда можете включить сервис + iptables-restore + позже.)

Прежде чем беспокоиться о брандмауэре, давайте получим экземпляры + etcd2 + для каждого члена кластера, которые общаются друг с другом.

Используйте CFSSL для генерации самоподписанных сертификатов

CFSSL - это набор инструментов для работы с сертификатами TLS / SSL, опубликованный CloudFlare. На момент написания этой статьи это инструмент, выбранный сопровождающими CoreOS для создания самозаверяющих сертификатов, в отличие от OpenSSL и ныне устаревшего + etcd-ca +.

Установите CFSSL на свой локальный компьютер

CFSSL требует работающей установки Go для установки из исходного кода. См. Https://www.digitalocean.com/community/tutorials/how-to-install-go-1-5-1-on-ubuntu-14-04 ---- это руководство по установке Go].

Убедитесь, что ваш + $ GOPATH + установлен правильно и добавлен в ваш + $ PATH +, затем используйте + go get + для установки команд + cfssl +:

export GOPATH=~/gocode
export PATH=$PATH:$GOPATH/bin
go get -u github.com/cloudflare/cfssl/cmd/cfssl
go get -u github.com/cloudflare/cfssl/...

В качестве альтернативного подхода предварительно собранные двоичные файлы можно получить по адресу pkg.cfssl.org. Сначала убедитесь, что + ~ / bin + существует и находится на вашем пути:

mkdir -p ~/bin
export PATH=$PATH:~/bin

Затем используйте + curl +, чтобы получить последние версии + cfssl + и + cfssljson + для вашей платформы:

curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/
curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/

Убедитесь, что двоичные файлы + cfssl + являются исполняемыми:

chmod +x ~/bin/cfssl
chmod +x ~/bin/cfssljson

Создайте центр сертификации

Теперь, когда команды + cfssl + установлены, мы можем использовать их для создания собственного центра сертификации, который мы будем использовать для подписи сертификатов для каждого из наших компьютеров с ОС CoreOS. Давайте начнем с создания и ввода нового каталога для хранения этих файлов:

mkdir ~/coreos_certs
cd ~/coreos_certs

Теперь создайте и откройте + ca-config.json в` + nano + `(или в вашем любимом текстовом редакторе):

nano ca-config.json

Вставьте и сохраните следующее, которое определяет, как + cfssl + будет выполнять подпись:

~ / Coreos_certs / ча-config.json

{
   "signing": {
       "default": {
           "expiry": "43800h"
       },
       "profiles": {
           "client-server": {
               "expiry": "43800h",
               "usages": [
                   "signing",
                   "key encipherment",
                   "server auth",
                   "client auth"
               ]
           }
       }
   }
}

Следует отметить, что + expiry +, в настоящее время установленное на 43800 часов (или 5 лет), и профиль + client-server +, который включает в себя как + server auth +, так и + client auth +. Нам нужны оба из них для одноранговой TLS.

Затем создайте и откройте + ca-csr.json.

nano ca-csr.json

Вставьте следующее, настраивая + CN + и массив + names + в соответствии с вашим местоположением и организацией. Безопасно использовать вымышленные значения для записи + hosts +, а также названия мест и организаций:

~ / Coreos_certs / ча-csr.json

{
   "CN": "My Fake CA",
   "hosts": [
       "example.net",
       "www.example.net"
   ],
   "key": {
       "algo": "rsa",
       "size": 2048
   },
   "names": [
       {
           "C": "US",
           "L": "CO",
           "O": "My Company",
           "ST": "Lyons",
           "OU": "Some Org Unit"
       }
   ]
}

При наличии + ca-csr.json и` + ca-config.json` создайте центр сертификации:

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

Создание и подписание сертификатов для машин CoreOS

Теперь, когда у нас есть центр сертификации, мы можем написать значения по умолчанию для компьютера с CoreOS:

Создайте и откройте + coreos-1.json +:

nano coreos-1.json

Вставьте и сохраните следующее, настроив его для частного IP-адреса * coreos-1 * (отображается в панели управления DigitalOcean при нажатии на отдельную каплю):

~ / Coreos_certs / coreos-1.json

{
   "CN": "",
   "hosts": [
       "",
       ".local",
       "127.0.0.1",
       ""
   ],
   "key": {
       "algo": "rsa",
       "size": 2048
   },
   "names": [
       {
           "C": "",
           "L": "",
           "ST": ""
       }
   ]
}

Наиболее важными частями являются + CN +, которым должно быть ваше имя хоста, и массив + hosts +, который должен содержать все:

  • ваше локальное имя хоста

  • + + 127.0.0.1

  • частный IP-адрес компьютера с операционной системой CoreOS (не его общедоступный IP-адрес)

Они будут добавлены в полученный сертификат как * https: //en.wikipedia.org/wiki/SubjectAltName [subjectAltNames] *. Соединения + etcd + (в том числе с локальным устройством обратной связи в + 127.0.0.1 +) требуют, чтобы сертификат имел SAN, совпадающую с именем подключающегося хоста.

При желании вы также можете изменить массив + names +, чтобы он отражал ваше местоположение. Опять же, безопасно использовать вымышленные значения для названий мест.

Повторите этот процесс для каждой оставшейся машины, создав соответствующие + coreos-2.json + и + coreos-3.json + с соответствующими записями + hosts +.

Теперь для каждого компьютера с CoreOS создайте подписанный сертификат и загрузите его на правильный компьютер:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server  | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:

Это создаст три файла (+ ca.pem +, + coreos-key.pem + и + coreos.pem +), удостоверится в правильности прав доступа к ключевому файлу и скопирует их через + scp + в * Домашний каталог core * на * coreos-1 *.

Повторите этот процесс для каждой из оставшихся машин, имея в виду, что каждый вызов команды будет перезаписывать предыдущий набор файлов сертификатов:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server  | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-3.json | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:

Проверьте etcd2 функциональность на coreos-1

Имея сертификаты, мы сможем запустить + fleetctl + на * coreos-1 *. Сначала войдите через SSH:

ssh -A core@

Далее попробуйте перечислить все машины в кластере:

fleetctl list-machines

Вы должны увидеть идентификатор для каждой машины в списке вместе с его частным IP-адресом:

OutputMACHINE     IP      METADATA
7cb57440... 10.132.130.187  -
d91381d4... 10.132.87.87    -
eeb8726f... 10.132.32.222   -

Если + fleetctl + зависает бесконечно, может потребоваться перезапустить кластер. Выход на локальный компьютер:

exit

Используйте SSH для отправки команд + reboot + на каждый компьютер с CoreOS:

ssh core@coreos-1_public_ip 'sudo reboot'
ssh core@coreos-2_public_ip 'sudo reboot'
ssh core@coreos-3_public_ip 'sudo reboot'

Подождите несколько секунд, заново подключитесь к * coreos-1 * и попробуйте + fleetctl + снова.

Настройте брандмауэр IPTables на членах кластера

При наличии сертификатов другие машины в локальной сети не смогут управлять вашим кластером или извлекать значения из + etcd2 +. Тем не менее, это хорошая идея - по возможности уменьшить доступную поверхность атаки. Чтобы ограничить доступ к сети, мы можем добавить несколько простых правил брандмауэра для каждой машины, блокируя большую часть трафика локальной сети из источников, отличных от одноранговых узлов в кластере.

Помните, что если мы включили службу + iptables-restore + в + cloud-config +, мы увидим сообщение об ошибке + systemd + при первом входе в систему с ОС CoreOS:

OutputCoreOS stable (766.5.0)
Failed Units: 1
 iptables-restore.service

Это позволяет нам знать, что, хотя служба включена, + iptables-restore + не удалось правильно загрузить. Мы можем диагностировать это с помощью + systemctl +:

systemctl status -l iptables-restore
Output● iptables-restore.service - Restore iptables firewall rules
  Loaded: loaded (/usr/lib64/systemd/system/iptables-restore.service; enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Wed 2015-11-25 00:01:24 UTC; 27min ago
 Process: 689 ExecStart=/sbin/iptables-restore /var/lib/iptables/rules-save (code=exited, status=1/FAILURE)
Main PID: 689 (code=exited, status=1/FAILURE)

Nov 25 00:01:24 coreos-2 systemd[1]: Starting Restore iptables firewall rules...
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Main process exited, code=exited, status=1/FAILURE
Nov 25 00:01:24 coreos-2 systemd[1]: Failed to start Restore iptables firewall rules.

Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Unit entered failed state.
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Failed with result 'exit-code'.

Здесь много информации, но наиболее полезной является строка, содержащая + iptables-restore [689] +, которая является именем процесса, который + systemd + пытался запустить вместе с его идентификатором процесса. Именно здесь мы часто находим фактические сообщения об ошибках сбойных служб.

Брандмауэр не удалось восстановить, потому что, хотя мы включили + iptables-restore + в + cloud-config +, мы еще не предоставили ему файл, содержащий наши нужные правила. Мы могли бы сделать это до того, как создали капли, за исключением того, что нет способа узнать, какие IP-адреса будут выделены капле перед ее созданием. Теперь, когда мы знаем каждый частный IP, мы можем написать набор правил.

Откройте новый файл в вашем редакторе, вставьте следующее и замените `, ` и ++ на частный IP-адрес каждого компьютера с ОС CoreOS. Вам также может понадобиться настроить раздел под + Accept весь трафик TCP / IP …​ +, чтобы отразить общедоступные сервисы, которые вы собираетесь предлагать из кластера, хотя эта версия должна хорошо работать в демонстрационных целях.

/ вар / Lib / Iptables / правила, за исключением

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Accept all loopback (local) traffic:
-A INPUT -i lo -j ACCEPT

# Accept all traffic on the local network from other members of
# our CoreOS cluster:
-A INPUT -i eth1 -p tcp -s  -j ACCEPT
-A INPUT -i eth1 -p tcp -s  -j ACCEPT
-A INPUT -i eth1 -p tcp -s  -j ACCEPT

# Keep existing connections (like our SSH session) alive:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Accept all TCP/IP traffic to SSH, HTTP, and HTTPS ports - this should
# be customized  for your application:




# Accept pings:
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT

Скопируйте вышеуказанное в буфер обмена, войдите в систему * coreos-1 * и откройте «+ rules-save +», используя https://www.digitalocean.com/community/tutorials/install-and-using-the-vim-text. -редактор на облачном сервере [Vim], текстовый редактор по умолчанию в CoreOS:

ssh -A core@
sudo vim /var/lib/iptables/rules-save

Оказавшись внутри редактора, введите +: set paste + и нажмите * Enter *, чтобы убедиться, что авто-отступ отключен, затем нажмите * i *, чтобы войти в режим вставки и вставить правила брандмауэра. Нажмите * Esc *, чтобы выйти из режима вставки, и *: wq *, чтобы записать файл и выйти.

Наконец, убедитесь, что файл имеет соответствующие разрешения (чтение и запись для пользователя, только чтение для группы и мира):

sudo chmod 0644 /var/lib/iptables/rules-save

Теперь мы должны быть готовы попробовать сервис снова:

sudo systemctl start iptables-restore

В случае успеха + systemctl + завершится без вывода сообщений. Мы можем проверить состояние брандмауэра двумя способами. Во-первых, используя + systemctl status:

sudo systemctl status -l iptables-restore

А во-вторых, перечисляя текущие правила + iptables +:

sudo iptables -v -L

Мы используем опцию + -v +, чтобы получить подробный вывод, который даст нам знать, к какому интерфейсу применяется данное правило.

Убедившись, что брандмауэр на * coreos-1 * настроен, выйдите из системы:

exit

Затем повторите этот процесс, чтобы установить + / var / lib / iptables / rules-save + на * coreos-2 * и * coreos-3 *.

Заключение

В этом руководстве мы определили базовый кластер CoreOS с тремя участниками, каждому из которых был предоставлен сертификат TLS / SSL для проверки подлинности и безопасности транспорта, и использовали брандмауэр для блокировки соединений с другими каплями в локальной сети центра обработки данных. Это помогает смягчить многие из основных проблем безопасности, связанных с использованием CoreOS в общей сети.

Отсюда вы можете применить методы, описанные в остальной части this серия при начале работы с CoreOS, для определения сервисов и управления ими.

Related