クラウドネイティブのヒント: ローカル K8s に自己署名 TLS 証明書を簡単にデプロイする

インターネットの急速な発展に伴い、セキュリティはますます私たちの注目の的となっています。 HTTPS は、贅沢なテクノロジーから現代の Web インタラクションの標準へと進化しました。これは情報保護のための重要なツールであるだけでなく、信頼と品質の象徴でもあります🛡️。ローカルの K8s 開発環境でアクセスするために HTTPS を使用する必要がある場合、TLS/SSL 証明書をどのように構成しますか?

今日は、K8s 環境で証明書に簡単に自己署名して、ローカル開発環境のセキュリティを向上させる方法をご紹介します。

1. 準備

1. Kindをインストールする

Kind の設定ファイルを生成する際に、Kind の extraPortMapping 設定オプションを利用して、ホストからノード上で実行されている Ingress コントローラーにポートを転送しました。

その役割は、ローカルホストがポート 80/443 を介して Ingress コントローラーに要求を送信できるようにすることです。

 cat << EOF > cluster.yaml kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 name: local nodes: - role: control-plane image: kindest/node:v1.25.3 extraPortMappings: - containerPort: 80 hostPort: 80 listenAddress: 127.0.0.1 - containerPort: 443 hostPort: 443 listenAddress: 127.0.0.1 EOF

生成された構成を使用して、K8s クラスターをローカルにインストールします。

 kind create cluster --config cluster.yaml

⚠️ extraPortMappings が設定されているため、複数の K8s クラスターをローカルにデプロイする必要がある場合は、ポートを調整するか、extraPortMappings 設定項目を削除する必要があります。

2. Traefikをインストールする

Traefik Labs チャートリポジトリを Helm に追加します。

 helm repo add traefik https://traefik.github.io/charts helm repo update

ここでは、websecure のホストポートを 443 に設定し、着信 HTTPS トラフィックが Traefik に正しくルーティングされるようにします。

 helm upgrade -i traefik \ --set ports.traefik.expose=true \ --set ports.websecure.hostPort=443 \ --set-string service.type=ClusterIP \ --namespace traefik \ --create-namespace \ traefik/traefik

3. Dnsmasqをインストールする

/etc/hosts は単純なドメインと IP アドレスのマッピングには便利ですが、静的であり、ワイルドカードやパターンマッチングをサポートしていないため、ドメインのすべてのサブドメインに同じ IP アドレスを設定することはできません。

Dnsmasq[1]は、DHCPサービスも提供できる軽量のDNSフォワードおよびリバースキャッシュサーバーです。簡単に設定および使用できるように設計されており、特に単純な DHCP および DNS サービスが必要な小規模ネットワーク環境でよく使用されます。

Dnsmasq は、より強力で柔軟性があり、集中化されたソリューションを提供すると言えます。インストール方法は次のとおりです。

 brew install dnsmasq

4. CFSSL/mkcertをインストールする

自己署名 SSL/TLS 証明書をローカルで生成するためのツールは多数あります。ここで2つ紹介します。各ツールには独自の特性と最適な用途があります。ニーズや好みに応じてお選びいただけます。

1つ目はCFSSL[2]です。インストール方法は次のとおりです。

 brew install cfssl

2番目の方法：mkcert[3]。インストール方法は以下になります。

 brew install mkcert

まとめ

これまでに、ローカルの K8s 開発環境でのインフラストラクチャの準備が完了しました。 Kind を通じて、ローカル Kubernetes クラスターの構築に成功しました。 Helm と Traefik を通じて、クラスターに強力なルーティングとリバースプロキシ機能を構成しました。最後に、Dnsmasq を通じて、従来の /etc/hosts 方式に代わる柔軟なローカル DNS ソリューションを提供しました。これらすべてにより、その後の TLS/SSL 証明書の構成のための強固な基盤が築かれました。

次に、次の段階に進み、K8s 開発環境で自己署名証明書を構成して、HTTPS 経由の安全なアクセスを有効にする方法を実際に検討します。好奇心を持って、私と一緒にクラウドネイティブの神秘的な世界を探検しましょう。 🚀

2. 自己署名証明書を作成する

まず、自己署名証明書を作成する必要があります。ここでは、このプロセスを完了するために CFSSL を使用することを選択します。

初期設定

次のコマンドを丁寧に入力して、光沢のある設定ファイル config.json を生成します✨

 cfssl print-defaults config > config.json

設定内容は必要に応じて若干調整できます

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

証明書を生成する

create-selfsign-cert.shスクリプトに以下を記述します。

 #!/usr/bin/env bash cn=$1 if [[ -z "$cn" ]]; then read -p "Common name: " cn fi extfile=$(mktemp) cat >"$extfile" <<INNER_EOF { "CN": "$cn", "hosts": [ "$cn" ], "key": { "algo": "ecdsa", "size": 256 }, "names": [ { "C": "CN", "L": "Shanghai", "O": "BaseBit", "OU": "XDP", "ST": "Shanghai" } ] } INNER_EOF function finish { rm "$extfile" } trap finish EXIT cfssl selfsign -config=config.json selfsign "$extfile" | cfssljson -bare "$cn" mv ${cn}-key.pem ${cn}.key mv ${cn}.pem ${cn}.crt

次に、次のコマンドを実行してワイルドカードドメイン名証明書を生成します。

 $(pwd)/create-selfsign-cert.sh "*.kind.cluster"

💡 ヒント: 実行後、次の 3 つのファイルが作成されます。

 ➜ ls |grep kind *.kind.cluster.crt # 自签名证书*.kind.cluster.csr # 证书签名请求(CSR)文件*.kind.cluster.key # 私钥文件

CFSSL のさらなる魅力については、公式 Web サイトにアクセスしてご自身で調べてみてください。

3. Kubernetes TLSシークレットを作成する

次に、自己署名証明書と秘密鍵を TLS シークレットとして Kubernetes に保存します。

 # 创建一个TLS Secret kubectl create secret tls tls-secret \ --key *.kind.cluster.key \ --cert *.kind.cluster.crt

4. TLSシークレットを使用するようにKubernetes Ingressを構成する

よし、これで準備はすべて完了です🎉、次はサービスを呼んで試してみましょう！

 # 创建一个Nginx Deployment kubectl create deployment nginx-deployment --image=nginx:1.25.3 # 暴露Deployment 作为一个Service kubectl expose deployment nginx-deployment --port=80

K8s IngressリソースでHTTPSを有効にするためにTLSシークレットを参照します。対応するドメイン名はnginx.kind.clusterです。

 kubectl apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx spec: tls: # 以下4 行是为了支持TLS - hosts: # - nginx.kind.cluster # secretName: tls-secret # rules: - host: nginx.kind.cluster http: paths: - path: / pathType: Prefix backend: service: name: nginx-deployment port: number: 80 EOF

5. Dnsmasqを設定する

ドメイン名はカスタマイズされているため、ローカルでも呪文を唱える必要があります。

ローカル IP からワイルドカード [サブ] ドメインを提供できるように、Dnsmasq 構成に次の情報を追加します。

 echo 'address=/kind.cluster/127.0.0.1' >> $(brew --prefix)/etc/dnsmasq.conf

前述のように、Kind クラスターのポートをホストにマッピングしたので、ここではクラスターホストの実際の IP アドレスではなく、127.0.0.1 のみを構成する必要があります。 Dnsmasq は、foo.kind.cluster や bar.kind.cluster などのサブドメインレコードの解決も試みるので、非常に便利です。

設定が完了しました。brewを使用してDnsmasqを再起動します。

 sudo brew services restart dnsmasq

また、.kind.cluster で終わるドメイン専用の DNS リゾルバも構成しました。

 cat <<EOF | sudo tee /etc/resolver/kind.cluster nameserver 127.0.0.1 EOF

最後に、dig コマンドを使用して、ドメイン名解決が正しく 127.0.0.1 を指していることを確認します。

 ➜ dig kind.cluster @127.0.0.1 ; <<>> DiG 9.10.6 <<>> kind.cluster @127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54402 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;kind.cluster. IN A ;; ANSWER SECTION: kind.cluster. 0 IN A 127.0.0.1 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Oct 29 07:31:11 CST 2023 ;; MSG SIZE rcvd: 57

🎉 検証してみましょう。

写真

6. 自己署名証明書の信頼

自己署名証明書を使用する場合の欠点は、ユーザーがこの Ingress を通じて公開されているサービスにアクセスすると、証明書が信頼できる証明機関によって発行されていないため、ブラウザに警告が表示されることです。この問題を解決するにはどうすればいいでしょうか?

実はとても簡単です。コンピュータ上で、この自己署名証明書を信頼されたルート証明書ストアに追加すると、接続が安全でない場合にブラウザで毎回警告が表示されなくなります。

macOSを例に挙げてみましょう

ステップ 1: .crt ファイルをダブルクリックします。これにより、キーチェーンアクセスアプリが開きます。キーチェーンアクセスで、証明書がインポートされたことがわかります。表示されない場合は、.crt ファイルをキーチェーンアクセスウィンドウに手動でドラッグすることもできます。

ステップ2: インポートした証明書を右クリックし、「情報を見る」を選択します。

写真

ステップ3: 「信頼」セクションを展開し、「この証明書を使用する場合」で「常に信頼」を選択します。

写真

ステップ4: 最後に検証してみましょう🎉

写真

CURL 経由で確認することもできますが、エラーは報告されなくなります。効果は以下のとおりです

➜ curl -v https://nginx.kind.cluster * Trying 127.0.0.1:443... * Connected to nginx.kind.cluster (127.0.0.1) port 443 (#0) * ALPN: offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 * ALPN: server accepted h2 * Server certificate: * subject: C=CN; ST=Shanghai; L=Shanghai; O=BaseBit; OU=XDP; CN=*.kind.cluster * start date: Oct 29 13:54:45 2023 GMT * expire date: Oct 29 13:59:45 2033 GMT * subjectAltName: host "nginx.kind.cluster" matched cert's "*.kind.cluster" * issuer: C=CN; ST=Shanghai; L=Shanghai; O=BaseBit; OU=XDP; CN=*.kind.cluster * SSL certificate verify ok. * using HTTP/2 ... < HTTP/2 200 ...

上記の手順を実行すると、ローカル開発環境で自己署名証明書を信頼し、正しく使用できるようになります。

しかし、より簡単な代替手段であるmkcertがあります。これは、面倒な設定をせずにローカル開発環境で直接信頼できる証明書を作成するのに役立ち、ローカル環境の設定を大幅に簡素化します。

 mkcert -install mkcert '*.kind.cluster'

試してみるのもいいかもしれません。これは CFSSL を完全に置き換えることができます。ローカル開発とテストには十分です。

裏面に記入

この記事では、比較的従来的なアプローチで自己署名証明書を作成しましたが、これは一部のシナリオでは真に「クラウドネイティブ」ではない可能性があります。次の記事では、証明書の要求と更新を自動化し、最新のKubernetesエコシステムとの統合と適応性を高めるように設計された、真にクラウドネイティブな自己署名証明書方式であるCert-Manager[4]について詳しく紹介します。 🚀