Giới thiệu

Nếu bạn dự định chạy một cụm CoreOS trong môi trường mạng ngoài tầm kiểm soát của bạn, chẳng hạn như trong trung tâm dữ liệu được chia sẻ hoặc trên internet công cộng, bạn có thể nhận thấy rằng etcd giao tiếp bằng cách thực hiện các yêu cầu HTTP không được mã hóa. Có thể giảm thiểu rủi ro của hành vi đó bằng cách cấu hình tường lửa IPTables trên mỗi nút trong cụm, nhưng một giải pháp hoàn chỉnh lý tưởng sẽ sử dụng lớp truyền tải được mã hóa.

May mắn thay, etcd hỗ trợ kết nối TLS / SSL ngang hàng, sao cho mỗi thành viên của một cụm được xác thực và tất cả các thông tin liên lạc đều được mã hóa. Trong hướng dẫn này, chúng ta sẽ bắt đầu bằng cách cung cấp một cụm đơn giản với ba thành viên, sau đó cấu hình các điểm cuối HTTPS và một tường lửa cơ bản trên mỗi máy.

Điều kiện tiên quyết

Hướng dẫn này xây dựng rất nhiều về các khái niệm được thảo luận trong giới thiệu về các thành phần hệ thống CoreOS và hướng dẫn này để thiết lập một cụm CoreOS trên DigitalOcean.

Bạn nên làm quen với những điều cơ bản của etcd, fleetctl, cloud-config tệp và tạo URL khám phá.

Để tạo và truy cập các máy trong cụm của bạn, bạn sẽ cần một khóa công khai SSH được liên kết với tài khoản DigitalOcean của bạn. Để biết thông tin chi tiết về cách sử dụng các khóa SSH với DigitalOcean, xem ở đây.

Nếu bạn muốn sử dụng API DigitalOcean để tạo các máy tính CoreOS, hãy tham khảo hướng dẫn này để biết thông tin về cách tạo và sử dụng Mã thông báo truy cập cá nhân có quyền ghi. Việc sử dụng API là tùy chọn, nhưng có thể giúp bạn tiết kiệm thời gian về lâu dài, đặc biệt nếu bạn dự đoán xây dựng các cụm lớn hơn.

Tạo URL khám phá mới

Truy xuất URL khám phá mới từ discovery.etcd.io, bằng cách truy cập https://discovery.etcd.io/new?size=3 trong trình duyệt của bạn và sao chép URL được hiển thị hoặc bằng cách sử dụng curl từ thiết bị đầu cuối trên máy cục bộ của bạn:

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

Lưu URL được trả lại; chúng tôi sẽ sử dụng nó trong cloud-config ngay.

Viết tệp Cloud-Config bao gồm cấu hình HTTPS

Chúng ta sẽ bắt đầu bằng cách viết một cloud-config. Các cloud-config sẽ được cung cấp dưới dạng dữ liệu người dùng khi khởi tạo mỗi máy chủ, xác định chi tiết cấu hình quan trọng cho cụm. Tệp này sẽ dài, nhưng không nên phức tạp hơn nhiều so với phiên bản trong hướng dẫn cụm cơ bản. Chúng tôi sẽ nói fleet một cách rõ ràng để sử dụng các điểm cuối HTTPS, cho phép một dịch vụ được gọi iptables-restore cho tường lửa của chúng tôi và viết ra các tệp cấu hình cho biết etcdfleet nơi tìm chứng chỉ SSL.

Mở thiết bị đầu cuối trên máy cục bộ của bạn, đảm bảo bạn đang ở trong thư mục chính và sử dụng nano (hoặc trình soạn thảo văn bản yêu thích của bạn) để tạo và mở ~/cloud-config.yml:

cd ~

nano cloud-config.yml

Dán các mục sau, sau đó thay đổi https://discovery.etcd.io/token bên trong etcd2 cho URL khám phá mà bạn đã xác nhận trong phần cuối cùng.

Bạn cũng có thể xóa iptables-restore , nếu bạn không muốn kích hoạt tường lửa.

Cẩn thận với vết lõm khi dán. Các cloud-config được viết bằng YAML, nhạy cảm với khoảng trắng. Xem nhận xét trong tệp để biết thông tin về các dòng cụ thể, sau đó chúng tôi sẽ xem xét một số phần quan trọng chi tiết hơn.

~/cloud-config.yml

#cloud-config

coreos:
  etcd2:
    # generate a new token for each unique cluster from https://discovery.etcd.io/new:
    discovery: https://discovery.etcd.io/token
    # 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
    # enable and start iptables-restore
    - name: iptables-restore.service
      enable: true
      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

Là bước tùy chọn, bạn có thể dán cloud-config vào Trình xác thực cấu hình Cloud Core chính thức và hãy nhấn Xác thực Cloud-Config.

Lưu file và thoát. Trong nano, bạn có thể thực hiện điều này với Ctrl-X để thoát, y để xác nhận viết tệp và Đi vào để xác nhận tên tệp cần lưu.

Hãy xem xét một số khối cụ thể từ cloud-init.yml. Đầu tiên fleet giá trị:

  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

Thông báo rằng etcd_servers được đặt thành https URL. Đối với thao tác HTTP đơn giản, giá trị này không cần phải được đặt. Tuy nhiên, nếu không có cấu hình rõ ràng, HTTPS sẽ thất bại. ($private_ipv4 là một biến được hiểu bởi quá trình khởi tạo CoreOS, không phải là biến mà bạn cần phải thay đổi.)

Tiếp theo chúng ta đến write_files khối. Giá trị được chia thành hệ thống tệp path, permissions mặt nạ và content, chứa nội dung mong muốn của một tệp. Ở đây, chúng tôi xác định rằng systemd các tệp đơn vị cho etcd2fleet dịch vụ nên thiết lập các biến môi trường trỏ đến chứng chỉ TLS / SSL mà chúng tôi sẽ tạo:

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
      ...

Trong khi chúng tôi nói với các dịch vụ nơi tìm các tệp chứng chỉ, chúng tôi chưa thể tự cung cấp các tệp. Để làm được điều đó, chúng ta cần phải biết địa chỉ IP riêng của mỗi máy CoreOS, chỉ có sẵn khi các máy đã được tạo.

Chú thích: Trên CoreOS giọt, nội dung của cloud-config không thể thay đổi sau khi Droplet được tạo và tệp được thực hiện lại trên mỗi lần khởi động. Bạn nên tránh sử dụng write-files cho bất kỳ cấu hình nào bạn có kế hoạch sửa đổi sau khi cụm của bạn được xây dựng, vì nó sẽ được thiết lập lại trong lần khởi động Droplet tiếp theo.

Dự phòng giọt

Bây giờ chúng ta có một cloud-config.yml xác định, chúng tôi sẽ sử dụng nó để cung cấp cho mỗi thành viên của cụm. Trên DigitalOcean, có hai cách tiếp cận cơ bản mà chúng ta có thể thực hiện: Thông qua Bảng điều khiển dựa trên web hoặc thực hiện cuộc gọi đến API DigitalOcean bằng cách sử dụng cURL từ dòng lệnh.

Sử dụng bảng điều khiển DigitalOcean

Tạo ba giọt CoreOS mới trong cùng một vùng trung tâm dữ liệu. Đảm bảo kiểm tra Mạng riêngBật dữ liệu người dùng mỗi lần.

  • coreos-1
  • coreos-2
  • coreos-3

bên trong Dữ liệu người dùng trường, dán nội dung của cloud-config.yml từ trên cao, đảm bảo bạn đã chèn URL khám phá của mình vào discovery trường gần đầu tệp.

Sử dụng API DigitalOcean

Là một phương pháp thay thế có thể lưu dán lặp đi lặp lại vào các trường, chúng ta có thể viết một tập lệnh Bash ngắn sử dụng curl để yêu cầu một Droplet mới từ API DigitalOcean với cloud-configvà gọi nó một lần cho mỗi Droplet. Mở một tệp mới có tên makecoreos.sh với nano (hoặc trình soạn thảo văn bản bạn chọn):

cd ~

nano makecoreos.sh

Dán và lưu tập lệnh sau, điều chỉnh regionsize các trường như mong muốn cho cụm của bạn (mặc định là nyc3512mb là tốt cho mục đích trình diễn, nhưng bạn có thể muốn một vùng khác nhau hoặc các giọt nhỏ hơn cho các dự án trong thế giới thực):

~/makecoreos.sh

#!/usr/bin/env bash

# A basic Droplet create request.
curl -X POST "https://api.digitalocean.com/v2/droplets" \
     -d'{"name":"'"$1"'","region":"nyc3","size":"512mb","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"

Bây giờ, hãy thiết lập các biến môi trường $DO_SSH_KEY_FINGERPRINT$TOKEN vào dấu vân tay của khóa SSH được liên kết với tài khoản DigitalOcean của bạn và Mã thông báo truy cập cá nhân API của bạn tương ứng.

Để biết thông tin về cách nhận Mã thông báo truy cập cá nhân và sử dụng API, hãy tham khảo hướng dẫn này.

Để tìm dấu vân tay của khóa được liên kết với tài khoản của bạn, hãy kiểm tra các Bảo vệ phần cài đặt tài khoản của bạn, Dưới Khóa SSH. Nó sẽ ở dạng một dấu vân tay khóa công cộng, cái gì đó như 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8.

Chúng tôi sử dụng export ở đây để các quá trình con của vỏ, như makecoreos.sh, sẽ có thể truy cập các biến. Cả hai phải được đặt trong trình bao hiện tại bất kỳ lúc nào tập lệnh được sử dụng hoặc lệnh gọi API sẽ không thành công:

export DO_SSH_KEY_FINGERPRINT="ssh_key_fingerprint"

export TOKEN="your_personal_access_token"

Chú thích: Nếu bạn vừa tạo Mã thông báo truy cập cá nhân cho API, hãy nhớ giữ cho nó tiện dụng và bảo mật. Không có cách nào để truy xuất nó sau khi nó được hiển thị cho bạn trong lần tạo đầu tiên và bất kỳ ai có mã thông báo đều có thể kiểm soát tài khoản DigitalOcean của bạn.

Khi chúng tôi đã đặt biến môi trường cho mỗi thông tin đăng nhập bắt buộc, chúng tôi có thể chạy tập lệnh để tạo từng giọt mong muốn. makecoreos.sh sử dụng tham số đầu tiên của nó để điền vào name trường trong cuộc gọi tới API:

bash makecoreos.sh coreos-1

bash makecoreos.sh coreos-2

bash makecoreos.sh coreos-3

Bạn sẽ thấy đầu ra JSON mô tả từng giọt mới, và cả ba sẽ xuất hiện trong danh sách các giọt của bạn trong bảng điều khiển. Có thể mất vài giây để họ hoàn tất khởi động.

Đăng nhập vào coreos-1

Cho dù bạn đã sử dụng Bảng điều khiển hay API, bạn sẽ có ba giọt đang chạy. Bây giờ là thời điểm tốt để lưu ý các IP công cộng và riêng tư của họ, có sẵn bằng cách nhấp vào một giọt riêng lẻ trong Bảng điều khiển, sau đó nhấp vào Cài đặt liên kết. Địa chỉ IP riêng của mỗi Droplet sẽ cần thiết khi tạo các chứng chỉ và cấu hình tường lửa.

Hãy kiểm tra một giọt. Đảm bảo rằng khóa SSH của bạn được thêm vào đại lý SSH cục bộ của bạn:

eval $(ssh-agent)

ssh-add

Tìm địa chỉ IP công khai của coreos-1 trong Bảng điều khiển DigitalOcean và kết nối với chuyển tiếp tác nhân SSH được bật:

ssh -A core@coreos-1_public_ip

Khi đăng nhập lần đầu vào bất kỳ thành viên nào của nhóm, chúng tôi có thể nhận được thông báo lỗi từ systemd:

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

Điều này chỉ ra rằng tường lửa chưa được cấu hình. Bây giờ, an toàn để bỏ qua thông báo này. (Nếu bạn đã chọn không bật tường lửa trong cloud-config, bạn sẽ không thấy thông báo lỗi. Bạn luôn có thể bật iptables-restore dịch vụ sau.)

Trước khi chúng ta lo lắng về tường lửa, hãy lấy etcd2 các cá thể trên mỗi thành viên của cụm đang nói chuyện với nhau.

Sử dụng CFSSL để tạo chứng chỉ tự ký

CFSSL là một bộ công cụ để làm việc với chứng chỉ TLS / SSL, được xuất bản bởi CloudFlare. Tại thời điểm viết bài này, đó là công cụ được lựa chọn của người bảo trì CoreOS để tạo ra các chứng chỉ tự ký, tùy thuộc vào OpenSSL và không được chấp nhận etcd-ca.

Cài đặt CFSSL trên máy cục bộ của bạn

CFSSL yêu cầu cài đặt Go đang hoạt động để cài đặt từ nguồn. Xem hướng dẫn này để cài đặt Go.

Hãy chắc chắn rằng bạn $GOPATH được đặt chính xác và được thêm vào $PATH, sau đó sử dụng go get để cài đặt cfssl lệnh:

export GOPATH=~/gocode

export PATH=$PATH:$GOPATH/bin

go get -u github.com/cloudflare/cfssl/cmd/cfssl

go get -u github.com/cloudflare/cfssl/...

Là một cách tiếp cận thay thế, các tệp nhị phân dựng sẵn có thể được truy xuất từ pkg.cfssl.org. Trước tiên hãy chắc chắn rằng ~/bin tồn tại và nằm trong đường dẫn của bạn:

mkdir -p ~/bin

export PATH=$PATH:~/bin

Sau đó sử dụng curl để truy xuất phiên bản mới nhất của cfsslcfssljson cho nền tảng của bạn:

curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/R1.1/cfssl_linux-amd64

curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/R1.1/cfssljson_linux-amd64

Hãy đảm bảo rằng cfssl các tệp nhị phân có thể thực thi được:

chmod +x ~/bin/cfssl

chmod +x ~/bin/cfssljson

Tạo một Tổ chức phát hành chứng chỉ

Bây giờ là cfssl các lệnh được cài đặt, chúng ta có thể sử dụng chúng để tạo ra một Certificate Authority tùy chỉnh mà chúng ta sẽ sử dụng để ký các chứng chỉ cho mỗi máy tính CoreOS của chúng ta. Hãy bắt đầu bằng cách tạo và nhập một thư mục mới để lưu trữ các tệp này trong:

mkdir ~/coreos_certs

cd ~/coreos_certs

Bây giờ, hãy tạo và mở ca-config.json trong nano (hoặc trình soạn thảo văn bản yêu thích của bạn):

nano ca-config.json

Dán và lưu phần sau, cấu hình cách cfssl sẽ ký:

~/coreos_certs/ca-config.json

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

Lưu ý ở đây là expiry, hiện được đặt thành 43800 giờ (hoặc 5 năm) và client-server tiểu sử, bao gồm cả server authclient auth tập quán. Chúng tôi cần cả hai loại này cho TLS ngang hàng.

Tiếp theo, tạo và mở ca-csr.json.

nano ca-csr.json

Dán phần sau, điều chỉnh CNnames mảng như mong muốn cho vị trí và tổ chức của bạn. An toàn để sử dụng các giá trị hư cấu cho hosts mục nhập cũng như tên địa điểm và tổ chức:

~/coreos_certs/ca-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"
        }
    ]
}

Nếu bạn muốn so sánh các giá trị này với các giá trị mặc định cho ca-config.jsonca-csr.json, bạn có thể in mặc định bằng cfssl. Dành cho ca-config.json, sử dụng:

cfssl print-defaults config

Dành cho ca-csr.json, sử dụng:

cfssl print-defaults csr 

Với ca-csr.jsonca-config.json tại chỗ, tạo Cơ quan cấp chứng chỉ:

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

Tạo và ký chứng chỉ cho các máy tính CoreOS

Bây giờ chúng ta có một Certificate Authority, chúng ta có thể viết các giá trị mặc định cho một máy CoreOS:

Tạo và mở coreos-1.json:

nano coreos-1.json

Dán và lưu các mục sau, điều chỉnh nó cho địa chỉ IP riêng của coreos-1 (hiển thị trong Bảng điều khiển DigitalOcean bằng cách nhấp vào một giọt riêng lẻ):

~/coreos_certs/coreos-1.json

{
    "CN": "coreos-1",
    "hosts": [
        "coreos-1",
        "coreos-1.local",
        "127.0.0.1",
        "coreos-1_private_ip"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "US",
            "L": "Lyons",
            "ST": "Colorado"
        }
    ]
}

Các phần quan trọng nhất là CN, tên máy chủ của bạn và hosts mảng, phải chứa tất cả:

  • tên máy chủ cục bộ của bạn
  • 127.0.0.1
  • địa chỉ IP riêng của máy tính CoreOS (không phải IP công khai)

Chúng sẽ được thêm vào chứng chỉ kết quả subjectAltNames. etcd kết nối (bao gồm cả thiết bị loopback cục bộ tại 127.0.0.1) yêu cầu chứng chỉ để có SAN khớp với tên máy chủ kết nối.

Bạn cũng có thể thay đổi names mảng để phản ánh vị trí của bạn, nếu muốn. Một lần nữa, nó an toàn để sử dụng các giá trị hư cấu cho các placenames.

Lặp lại quá trình này cho mỗi máy còn lại, tạo một kết hợp coreos-2.jsoncoreos-3.json với thích hợp hosts mục.

Chú thích: Nếu bạn muốn xem xét các giá trị mặc định cho coreos-1.json, bạn có thể dùng cfssl:

cfssl print-defaults csr 

Bây giờ, đối với mỗi máy CoreOS, tạo một chứng chỉ đã ký và tải nó lên máy chính xác:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-1.json | cfssljson -bare coreos

chmod 0644 coreos-key.pem

scp ca.pem coreos-key.pem coreos.pem core@coreos-1_public_ip:

Điều này sẽ tạo ba tệp (ca.pem, coreos-key.pemcoreos.pem), hãy đảm bảo quyền là chính xác trên keyfile và sao chép chúng qua scp đến cốt lõiThư mục chính của nhà trên coreos-1.

Lặp lại quá trình này cho từng máy còn lại, lưu ý rằng mỗi lệnh gọi của lệnh sẽ ghi đè lên tập các tệp chứng chỉ trước đó:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-2.json | cfssljson -bare coreos

chmod 0644 coreos-key.pem

scp ca.pem coreos-key.pem coreos.pem core@coreos-2_public_ip:

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@coreos-3_public_ip:

Kiểm tra etcd2 Chức năng trên coreos-1

Với giấy chứng nhận tại chỗ, chúng tôi sẽ có thể chạy fleetctl trên coreos-1. Đầu tiên, đăng nhập qua SSH:

ssh -A core@coreos-1_public_ip

Tiếp theo, hãy thử liệt kê tất cả các máy trong cluster:

fleetctl list-machines

Bạn sẽ thấy mã định danh cho mỗi máy được liệt kê cùng với địa chỉ IP riêng của nó:

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

Nếu fleetctl treo vô thời hạn, có thể cần phải khởi động lại cụm. Thoát khỏi máy cục bộ của bạn:

exit

Sử dụng SSH để gửi reboot lệnh cho mỗi máy tính 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'

Đợi một chút, kết nối lại với coreos-1, và cố gắng fleetctl lần nữa.

Cấu hình tường lửa IPTables trên các thành viên Cluster

Với chứng chỉ tại chỗ, các máy khác trên mạng cục bộ không thể kiểm soát cụm của bạn hoặc trích xuất các giá trị từ etcd2. Tuy nhiên, bạn nên giảm bề mặt tấn công sẵn có nếu có thể. Để hạn chế tiếp xúc với mạng của chúng tôi, chúng tôi có thể thêm một số quy tắc tường lửa đơn giản cho mỗi máy, chặn lưu lượng truy cập mạng cục bộ nhất từ ​​các nguồn khác với các máy ngang hàng trong cụm.

Hãy nhớ rằng, nếu chúng tôi đã bật iptables-restore dịch vụ trong cloud-config, chúng ta sẽ thấy systemd thông báo lỗi khi đăng nhập lần đầu vào máy CoreOS:

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

Điều này cho chúng tôi biết rằng, mặc dù dịch vụ được bật, iptables-restore không thể tải chính xác. Chúng tôi có thể chẩn đoán điều này bằng cách sử dụng 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 iptables-restore[689]: Can't open /var/lib/iptables/rules-save: No such file or directory
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'.

Có rất nhiều thông tin ở đây, nhưng dòng hữu ích nhất là dòng chứa iptables-restore[689], đó là tên của quá trình systemd đã cố gắng chạy cùng với id tiến trình của nó. Đây là nơi chúng tôi thường tìm thấy đầu ra lỗi thực tế của các dịch vụ không thành công.

Tường lửa không thể phục hồi vì, trong khi chúng tôi đã bật iptables-restore trong cloud-config, chúng tôi chưa cung cấp cho nó một tệp chứa các quy tắc mong muốn của chúng tôi. Chúng ta có thể làm điều này trước khi tạo ra các giọt, ngoại trừ việc không có cách nào để biết địa chỉ IP nào sẽ được cấp phát cho một giọt nhỏ trước khi tạo ra nó. Bây giờ chúng ta biết mỗi IP riêng, chúng ta có thể viết một ruleset.

Mở tệp mới trong trình chỉnh sửa của bạn, dán phần sau và thay thế coreos-1_private_ip, coreos-2_private_ipcoreos-3_private_ip với địa chỉ IP riêng của mỗi máy CoreOS. Bạn cũng có thể cần điều chỉnh phần bên dưới Accept all TCP/IP traffic... để phản ánh các dịch vụ công cộng mà bạn định cung cấp từ cụm, mặc dù phiên bản này sẽ hoạt động tốt cho mục đích trình diễn.

/var/lib/iptables/rules-save

*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 coreos-1_private_ip -j ACCEPT

-A INPUT -i eth1 -p tcp -s coreos-2_private_ip -j ACCEPT

-A INPUT -i eth1 -p tcp -s coreos-3_private_ip -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:

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

# 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

Sao chép phần trên vào khay nhớ tạm của bạn, đăng nhập vào coreos-1, và mở ra rules-save sử dụng Vim, trình soạn thảo văn bản mặc định trên CoreOS:

ssh -A core@coreos-1_public_ip

sudo vim /var/lib/iptables/rules-save

Khi bên trong trình chỉnh sửa, hãy nhập :set paste và hãy nhấn Đi vào để đảm bảo rằng tự động thụt lề được tắt, sau đó nhấn tôi để vào chế độ chèn và dán các quy tắc tường lửa của bạn. nhấn Esc rời khỏi chế độ chèn và : wq để viết tệp và thoát.

Cảnh báo: Hãy chắc chắn rằng có một dòng mới trên dòng cuối cùng của tập tin, hoặc IPTables có thể thất bại với các lỗi cú pháp khó hiểu, mặc dù tất cả các lệnh trong tập tin xuất hiện chính xác.

Cuối cùng, hãy đảm bảo rằng tệp có quyền thích hợp (đọc và ghi cho người dùng, chỉ đọc cho nhóm và thế giới):

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

Bây giờ chúng ta sẽ sẵn sàng để thử lại dịch vụ:

sudo systemctl start iptables-restore

Nếu thành công, systemctl sẽ thoát âm thầm. Chúng ta có thể kiểm tra trạng thái của tường lửa theo hai cách. Đầu tiên, bằng cách sử dụng systemctl status:

sudo systemctl status -l iptables-restore

Và thứ hai bằng cách liệt kê hiện tại iptables tự quy tắc:

sudo iptables -v -L

Chúng tôi sử dụng -v tùy chọn để có được đầu ra tiết, điều này sẽ cho chúng ta biết giao diện nào áp dụng cho quy tắc nhất định.

Khi bạn đã tự tin rằng tường lửa trên coreos-1 được cấu hình, đăng xuất:

exit

Tiếp theo, lặp lại quá trình này để cài đặt /var/lib/iptables/rules-save trên coreos-2coreos-3.

Phần kết luận

Trong hướng dẫn này, chúng tôi đã định nghĩa một cụm CoreOS cơ bản với ba thành viên, cung cấp cho mỗi chứng chỉ TLS / SSL để xác thực và bảo mật giao thông và sử dụng tường lửa để chặn các kết nối từ các giọt khác trên mạng trung tâm dữ liệu cục bộ. Điều này giúp giảm thiểu nhiều mối quan tâm bảo mật cơ bản liên quan đến việc sử dụng CoreOS trên một mạng chia sẻ.

Từ đây, bạn có thể áp dụng các kỹ thuật trong phần còn lại của loạt bài này về việc bắt đầu với CoreOS để xác định và quản lý dịch vụ.