GALAXY TECH
Chuyên gia Công nghệ
Thứ hai, 07/12/2015 | 00:00 GMT+7

Cách bảo mật cụm CoreOS của bạn bằng TLS / SSL và các quy tắc firewall

Nếu bạn đang dự định chạy một cụm CoreOS trong môi trường mạng nằm ngoài tầm kiểm soát của bạn, chẳng hạn như trong trung tâm dữ liệu dùng chung 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 đưa ra 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 firewall 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ẽ là sử dụng lớp truyền tải được mã hóa.

May mắn là etcd hỗ trợ các kết nối TLS / SSL ngang hàng, để mỗi thành viên của một cụm đều được xác thực và tất cả giao tiếp đều được mã hóa. Trong hướng dẫn này, 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 điểm cuối HTTPS và firewall cơ bản trên mỗi máy.

Yêu cầu

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

Bạn nên làm quen với các kiến thức cơ bản về etcd , fleetctl , file cloud-config 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 cần public key SSH được liên kết với account DigitalOcean của bạn . Để biết thông tin chi tiết về cách sử dụng SSH key với DigitalOcean, xem tại đây .

Nếu bạn muốn sử dụng API DigitalOcean để tạo các máy CoreOS của bạn , 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ã truy cập cá nhân với 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ự kiế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ừ explore.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ừ terminal trên máy local của bạn :

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

Lưu URL trả về; ta sẽ sớm sử dụng nó trong cloud-config của ta .

Viết file cấu hình cloud bao gồm cấu hình HTTPS

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

Mở một terminal trên máy local của bạn, đảm bảo bạn đang ở trong folder chính và sử dụng nano (hoặc editor yêu thích của bạn) để tạo và mở ~/cloud-config.yml :

  • cd ~ 
  • nano cloud-config.yml

Dán phần sau, sau đó thay đổi https://discovery.etcd.io/token trong phần etcd2 thành URL khám phá mà bạn đã xác nhận trong phần trước.

Bạn cũng có thể xóa phần iptables-restore nếu không muốn bật firewall .

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

~ / 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 Server 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à một bước tùy chọn, bạn có thể dán cloud-config của bạn vào Trình xác thực cấu hình cloud CoreOS chính thức và nhấn Xác thực cấu hình cloud .

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

Hãy xem xét một số khối cụ thể từ cloud-init.yml . Đầu tiên, các giá trị của 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

Lưu ý etcd_servers được đặt thành URL https . Đối với hoạt động 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ẽ không thành công. ( $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à một biến bạn cần thay đổi.)

Tiếp theo ta đến với khối write_files . Các giá trị được chia thành path hệ thống file , mặt nạ permissions và content , chứa các nội dung mong muốn của file . Ở đây, ta chỉ định rằng các file đơn vị systemd cho các dịch vụ etcd2 và fleet phải cài đặt các biến môi trường trỏ đến certificate TLS / SSL mà ta 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       ...

Mặc dù ta cho các dịch vụ biết nơi tìm file certificate , nhưng ta vẫn chưa thể tự cung cấp file . Để làm được điều đó, ta cần biết địa chỉ IP riêng của mỗi máy CoreOS, địa chỉ này chỉ khả dụng sau khi các máy đã được tạo.

Lưu ý: Trên CoreOS Server, không thể thay đổi nội dung của cloud-config sau khi Server được tạo và file được thực thi lại mỗi lần khởi động. Bạn nên tránh sử dụng phần write-files cho bất kỳ cấu hình nào bạn định sửa đổi sau khi cụm của bạn được xây dựng, vì nó sẽ được đặt lại vào lần tiếp theo Server khởi động.

Các server cung cấp

Bây giờ ta đã định nghĩa cloud-config.yml , ta sẽ sử dụng nó để cung cấp cho từng thành viên của cụm. Trên DigitalOcean, có hai cách tiếp cận cơ bản mà ta có thể thực hiện: Qua Control panel dựa trên web hoặc thực hiện lệnh gọi đến API DigitalOcean bằng cURL từ dòng lệnh.

Sử dụng Control panel DigitalOcean

Tạo ba server 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êng tư và Bật dữ liệu user mỗi lần.

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

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

Sử dụng API DigitalOcean

Là một cách tiếp cận thay thế có thể tiết kiệm việc dán lặp đi lặp lại vào các trường, ta có thể viết một đoạn mã Bash ngắn sử dụng curl để yêu cầu một server mới từ API DigitalOcean với cloud-config của ta và gọi nó một lần cho mỗi server . Mở một file mới có tên makecoreos.sh bằng nano (hoặc editor mà bạn chọn):

  • cd ~ 
  • nano makecoreos.sh

Dán và lưu tập lệnh sau, điều chỉnh các trường region và size theo mong muốn cho cụm của bạn (mặc định là nyc3 và 512mb là phù hợp cho mục đích demo , nhưng bạn có thể cần một vùng khác hoặc các server lớn hơn cho các dự án trong thế giới thực):

~ / makecoreos.sh
#!/usr/bin/env bash  # A basic Server create request. curl -X POST "https://api.digitalocean.com/v2/server" \      -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 đặt các biến môi trường $DO_SSH_KEY_FINGERPRINT và $TOKEN thành $DO_SSH_KEY_FINGERPRINT tham chiếu của SSH key được liên kết với account DigitalOcean và Mã 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ã 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 fingerprint của khóa được liên kết với account của bạn, hãy kiểm tra phần Bảo mật trong cài đặt account của bạn , bên dưới Khóa SSH . Nó sẽ ở dạng tệp tham chiếu public key , giống như 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8 .

Ta sử dụng export ở đây để các tiến trình con của shell, như makecoreos.sh , sẽ có thể truy cập các biến. Cả hai phải được đặt trong shell hiện tại bất kỳ khi nào tập lệnh được sử dụng, nếu không 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"

Lưu ý: Nếu bạn vừa tạo Mã truy cập cá nhân cho API, hãy nhớ giữ nó tiện dụng và an toàn. Không có cách nào để lấy 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 account DigitalOcean của bạn.

Khi ta đã đặt các biến môi trường cho từng thông tin đăng nhập bắt buộc, ta có thể chạy tập lệnh để tạo từng Server mong muốn. makecoreos.sh sử dụng tham số đầu tiên của nó để điền vào trường name trong lệnh 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 kết quả JSON mô tả từng server mới và cả ba sẽ xuất hiện trong danh sách các server của bạn trong Control Panel. Có thể mất vài giây để chúng khởi động xong.

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

Cho dù bạn đã sử dụng Control panel hay API, bây giờ bạn sẽ có ba server đang chạy. Bây giờ là thời điểm tốt để ghi chú lại các IP công khai và riêng tư của họ, những IP này khả dụng bằng cách nhấp vào từng server riêng lẻ trong Control panel , sau đó nhấp vào liên kết Cài đặt . Địa chỉ IP riêng của mỗi Server cần thiết khi tạo certificate và cấu hình firewall .

Hãy thử nghiệm một server . Đảm bảo rằng SSH key của bạn được thêm vào đại lý SSH tại local của bạn:

  • eval $(ssh-agent) 
  • ssh-add

Tìm địa chỉ IP công khai của coreos-1 trong Control panel 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

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

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

Điều này cho thấy rằng firewall chưa được cấu hình . Hiện tại, có thể yên tâm bỏ qua thông báo này. (Nếu bạn chọn không bật firewall trong cloud-config của bạn , bạn sẽ không thấy thông báo lỗi. Bạn luôn có thể bật dịch vụ iptables-restore sau.)

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

Sử dụng CFSSL để tạo certificate tự ký

CFSSL là một bộ công cụ để làm việc với certificate 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 các nhà bảo trì CoreOS lựa chọn để tạo certificate tự ký, ưu tiên cho OpenSSL và etcd-ca hiện không được dùng nữa.

Cài đặt CFSSL trên máy local 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 .

Đảm bảo rằng $GOPATH của bạn được đặt chính xác và được thêm vào $PATH của bạn, sau đó sử dụng go get để cài đặt các lệnh 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/...

Là một cách tiếp cận thay thế, các file binary được tạo sẵn có thể được truy xuất từ pkg.cfssl.org . Trước tiên, hãy đảm bảo ~/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 các version mới nhất của cfssl và cfssljson 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

Đảm bảo rằng các file binary cfssl có thể thực thi được:

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

Tạo Tổ chức phát hành certificate

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

  • mkdir ~/coreos_certs 
  • cd ~/coreos_certs

Bây giờ, hãy tạo và mở ca-config.json bằng nano (hoặc editor 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ẽ thực hiện việc 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à profile client-server , bao gồm cả sử dụng client auth server auth và client auth . Ta cần cả hai thứ 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 CN và mảng names như mong muốn cho vị trí và tổ chức của bạn. Thật an toàn khi sử dụng các giá trị hư cấu cho mục nhập hosts cũng như địa điểm và tên 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.json và ca-csr.json , bạn có thể in các giá trị mặc định bằng cfssl . Đối với ca-config.json , hãy sử dụng:

  • cfssl print-defaults config

Đối với ca-csr.json , hãy sử dụng:

  • cfssl print-defaults csr

Với ca-csr.json và ca-config.json tại chỗ, hãy tạo Tổ chức phát hành certificate :

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

Tạo và ký certificate cho máy CoreOS

Bây giờ ta đã có Tổ chức phát hành certificate , ta có thể viết các giá trị mặc định cho máy CoreOS:

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

  • nano coreos-1.json

Dán và lưu phần sau, điều chỉnh nó cho địa chỉ IP riêng của coreos-1 (hiển thị trong Control panel DigitalOcean bằng cách nhấp vào một server 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 , phải là tên server của bạn và mảng hosts , phải chứa tất cả:

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

Chúng sẽ được thêm vào certificate kết quả dưới dạng subjectAltNames . etcd kết nối etcd (bao gồm cả thiết bị lặp local tại 127.0.0.1 ) certificate request phải có SAN trùng với tên server kết nối.

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

Lặp lại quy trình này cho từng máy còn lại, tạo một coreos-2.json và coreos-3.json phù hợp với các mục hosts thích hợp.

Lưu ý: Nếu bạn muốn xem xét các giá trị mặc định cho coreos-1.json , bạn có thể sử dụng cfssl :

  • cfssl print-defaults csr

Bây giờ, đối với mỗi máy CoreOS, hãy tạo một certificate đã ký và tải nó lên đúng máy:

  • 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:

Thao tác này sẽ tạo ba file ( ca.pem , coreos-key.pem và coreos.pem ), đảm bảo các quyền trên keyfile là chính xác và sao chép chúng qua scp vào folder chính của core trên coreos-1 .

Lặp lại quá trình này cho từng máy còn lại, lưu ý mỗi lần gọi lệnh sẽ overrides tập hợp file certificate 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 chức năng etcd2 trên coreos-1

Với các certificate có sẵn, ta 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 cụm:

  • fleetctl list-machines

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

Output
MACHINE     IP      METADATA 7cb57440... 10.132.130.187  - d91381d4... 10.132.87.87    - eeb8726f... 10.132.32.222   -

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

  • exit

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

Chờ một lát, kết nối lại với coreos-1 và thử lại fleetctl .

Cấu hình firewall IPTables trên các thành viên cụm

Với các certificate tại chỗ, các máy khác trong mạng local sẽ không thể kiểm soát cụm của bạn hoặc extract các giá trị từ etcd2 . Tuy nhiên, bạn nên giảm bề mặt tấn công có sẵn nếu có thể. Để hạn chế sự tiếp xúc với mạng của ta , ta có thể thêm một số luật firewall đơn giản cho mỗi máy, chặn hầu hết lưu lượng mạng local từ các nguồn khác với các máy ngang hàng trong cụm.

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

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

Điều này cho ta biết rằng, mặc dù dịch vụ được kích hoạt nhưng iptables-restore không thể tải chính xác. Ta 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 process systemd đã cố gắng chạy cùng với process id của nó. Đây là nơi ta thường tìm thấy kết quả lỗi thực tế của các dịch vụ bị lỗi.

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

Mở file mới trong editor , dán file sau và thay thế coreos-1_private_ip , coreos-2_private_ip và coreos-3_private_ip bằng đị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 dự định cung cấp từ cụm, mặc dù version này sẽ hoạt động tốt cho mục đích demo .

/ 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 ở trên vào clipboard của bạn, đăng nhập vào coreos-1 và mở rules-save bằng Vim , editor mặc định trên CoreOS:

  • ssh -A core@coreos-1_public_ip 
  • sudo vim /var/lib/iptables/rules-save

Khi ở bên trong editor , hãy nhập :set paste và nhấn Enter đảm bảo tắt tính năng tự động thụt lề, sau đó nhấn i để vào chế độ insert và dán các luật firewall của bạn. Nhấn Esc để thoát khỏi chế độ insert và : wq để ghi file và thoát.

Cảnh báo: Đảm bảo có một dòng mới ở dòng cuối cùng của file , nếu không IPTables có thể không thành công với các lỗi cú pháp khó hiểu, mặc dù tất cả các lệnh trong file đều đúng.

Cuối cùng, hãy đảm bảo file có các quyền thích hợp (đọc và ghi cho user , chỉ đọc cho group và thế giới):

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

Bây giờ ta đã 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. Ta có thể kiểm tra trạng thái của firewall 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ê chính các luật iptables hiện tại:

  • sudo iptables -v -L

Ta sử dụng tùy chọn -v để nhận kết quả dài dòng, điều này sẽ cho ta biết giao diện mà một luật nhất định áp dụng cho.

Khi bạn chắc chắn rằng firewall trên coreos-1 đã được cấu hình , hãy đă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-2 và coreos-3 .

Kết luận

Trong hướng dẫn này, ta đã xác định một cụm CoreOS cơ bản với ba thành viên, cung cấp cho mỗi thành viên một certificate TLS / SSL để xác thực và bảo mật truyền tải, đồng thời sử dụng firewall để chặn kết nối từ các server khác trên mạng trung tâm dữ liệu local . Điều này giúp giảm thiểu nhiều lo ngại về bảo mật cơ bản liên quan đến việc sử dụng CoreOS trên 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 khi bắt đầu với CoreOS để xác định và quản lý các dịch vụ.

Tags:

Các tin liên quan