KubernetesでNginx Ingress + Cert-Managerを使用して自動Httpsを実現する

Kubernetes クラスターで HTTPS プロトコルを使用するには、証明書マネージャーと自動証明書発行サービスが必要です。 HTTPS サービスは主に Ingress を通じて公開されるため、Ingress コントローラーが必要であり、HTTPS とそのルーティングを有効にするように構成する必要があります。

cert-manager は、Kubernetes クラスター内で一連のデプロイメント リソースとして実行されます。

CustomResourceDefinitions (CRD) は、証明機関を構成し、証明書を要求するために使用されます。

cert-managerをインストールする

通常のマニフェストを使用してインストールする

すべてのリソース (CRD cert-manager、名前空間、および webhook コンポーネント) は、単一の YAML マニフェストに含まれています。

CRD と cert-manager をインストールします。

 # Kubernetes 1.16 以上
 $ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager.yaml
  # Kubernetes <1.16
  $ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager-legacy.yaml

PS: k8s のバージョンに応じて選択してください。

helmを使用してインストールする

準備：

 #cert-manager の名前空間を作成する
 $ kubectl 名前空間 cert-manager を作成します
 #Jetstack Helmリポジトリを追加する
 helm リポジトリに jetstack を追加します https://charts.jetstack.io
  #ローカルHelmチャートリポジトリキャッシュを更新する
 $ helm リポジトリの更新

kubectl コマンドを使用して CustomResourceDefinition リソースをインストールします。

 # Kubernetes 1.15 以上
 $ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager.crds.yaml
  # Kubernetes <1.15
  $ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager-legacy.crds.yaml

helm をインストールするときに --set installCRDs=true を設定することもできます。

 # ヘルムv3+
  $ ヘルムインストール\
  証明書マネージャー jetstack/証明書マネージャー \
  --namespace 証明書マネージャー \
  --バージョン v1.1.0 \
  # --set installCRDs=true
  $ ヘルムインストール\
  証明書マネージャー --namespace 証明書マネージャー \
  --set ingressShim.defaultIssuerName=letsencrypt-prod \
  --set ingressShim.defaultIssuerKind=ClusterIssuer \
  --version v1.1.0 ジェットスタック/証明書マネージャー
 # 上記のコマンドの 2 つのセットは、TLS を自動化するための kubernetes.io/tls-acme: "true" アノテーションをサポートするために使用されます。
  ヘルムv2
  $ ヘルムインストール\
  --name 証明書マネージャー \
  --namespace 証明書マネージャー \
  --バージョン v1.1.0 \
  ジェットスタック/証明書マネージャー \
  # --set installCRDs=true

インストールを確認します。

 $ kubectl ポッドを取得します --namespace cert-manager
  名前 準備完了 ステータス 再起動 年齢
 cert-manager-bcd4f8795-zpxsw 1/1 実行中 0 2分
 cert-manager-cainjector-78cbd59555-dhsp8 1/1 実行中 0 2m
  cert-manager-webhook-756d477cc4-j5mzt 1/1 実行中 0 2分

証明書マネージャーが正しく設定され、基本的な証明書タイプを発行できることを確認します。

 $ cat <<EOF> テストリソース.yaml
  APIバージョン: v1
  種類: 名前空間
 メタデータ:
  名前: cert-manager-test
  ---
  APIバージョン: cert-manager.io/v1
  種類: 発行者
 メタデータ:
  名前: テスト自己署名
 名前空間: cert-manager-test
  仕様:
  自己署名: {}
  ---
  APIバージョン: cert-manager.io/v1
  種類: 証明書
 メタデータ:
  名前: 自己署名証明書
 名前空間: cert-manager-test
  仕様:
  dns名:
  - example.com
  シークレット名: selfsigned-cert-tls
  発行者参照:
  名前: テスト自己署名
 終了

テスト リソースを作成します。

 $ kubectl apply -f テストリソース.yaml
  #新しく作成された証明書のステータスを確認します。 cert-managerが証明書要求を処理するまで数秒待つ必要がある場合があります。
  $ kubectl 証明書の説明 -n cert-manager-test
  #最後にテストリソースをクリーンアップします
 $ kubectl 削除 -f テストリソース.yaml

証明書署名サービスを作成する

cert-manager をインストールした後、証明書を発行するためのクラスター発行者または発行者リソースを定義する必要があります。これらのリソースは、特定の署名権限を表します。手順については公式ドキュメントを参照してください。複数の発行タイプがサポートされており、ここでは ACME を使用します。

ACME には 2 つの認証方法があります。

• HTTP01: パブリック IP を持つイングレス リソースに適用されます。シンプルな構成。
• DNS01: パブリック IP のないイントラネット内の k8s クラスターに適用可能です。自動化を実現するには、サードパーティのツールが必要です。もちろん、cert-manager はデフォルトでいくつかのドメイン名サービスプロバイダーもサポートしており、サポートされていないベンダー向けに一般的な webhook メソッドも提供しています。リストにない場合は、例を使用して自分で実装できます。

簡単に言うと、HTTP01 は、証明書を申請する必要があるドメイン名を要求することによって Web サイトを検証します。たとえば、パスwww.example.com/.well-know/acme-challenge/CR-WBJ-XXXXXXXX 。前提として、このパスはパブリック ネットワーク上で正常にアクセス可能であり、ドメイン名解決によってイングレスのパブリック ネットワーク アドレスが正しく指定されている必要があります。つまり、イングレスのパブリック ネットワーク IP とドメイン名解決が正しいことを確認します。そうして初めて証明書が発行されます。

簡単に言うと、DNS01 は、ACME サーバーが txt 解決を生成することを意味し、これを DNS 管理バックエンドに正しく追加する必要があります。 ACME サーバーが解決が有効であることを確認した場合にのみ、ドメイン名がお客様のものであることを証明し、証明書を発行できます。

HTTP01

ClusterIssuer を構成します。

PS: letsencrypt-staging 公式 Web サイトで提供されているインスタンスは一時的なものです。この ClusterIssuer を使用すると、一時的な Lets Encrypt 証明書がデフォルトで生成されます。一時証明書はCN=Fake LE Intermediate X1によって発行されます。この証明書を取得した場合、申請は自動的に成功したことを意味します。 ClusterIssuer YAML内の ACME サーバーをhttps://acme-v02.api.letsencrypt.org/directoryに置き換えます。 letsencrypt-prod という名前の新しい ClusterIssuer を作成します。メールアドレスも変更する必要があります。

公式の例:

 api バージョン: cert-manager.io/v1 ​ ​ ​
 種類: ClusterIssuer
 メタデータ:
 名前: letsencrypt - ステージング
仕様:
 アクメ：
 # このメールアドレスを自分のメールアドレスに置き換える必要があります。
 # Let 's Encryptはこれを使用して有効期限切れについて連絡します
# 証明書、 およびアカウントに関連する問題。
 メールアドレス: [email protected]
 サーバー: https://acme-staging-v02.api.letsencrypt.org/directory
 秘密鍵シークレット参照:
 # アカウントの秘密鍵を保存するために使用される秘密リソース。
 名前: 例- 発行者- アカウント- キー
# nginx を使用して単一のチャレンジソルバーHTTP01 を追加します
ソルバー:
 - http01 :
 入口:
 クラス: nginx

letsencrypt-prod:

 APIバージョン: cert-manager.io/v1
  種類: ClusterIssuer
  メタデータ:
  名前:letsencrypt-prod
  仕様:
  アクメ：
  # このメールアドレスを自分のメールアドレスに置き換える必要があります。
  # Let's Encryptはこれを使用して、有効期限切れについて連絡します
 # 証明書、およびアカウントに関連する問題。
  メールアドレス: [email protected]
  サーバー: https://acme-v02.api.letsencrypt.org/directory
  プライベートキーシークレットリファレンス:
  # アカウントの秘密鍵を保存するために使用される秘密リソース。
  名前:letsencrypt-prod-account-key
  # nginx を使用して単一のチャレンジ ソルバー HTTP01 を追加します。
  ソルバー:
  - http01:
  進入:
  クラス: nginx

次に、Clusterissuer リソースを直接作成できます。

 $ kubectl create -f クラスター発行者.yaml
  clusterissuer.certmanager.k8s.io「letsencrypt-prod」が作成されました
 $ kubectl クラスター発行者を取得します
 名前 年齢
 letsencrypt-prod 16秒

パブリック Ingress リソースとクラスターがないため、ここではテストしません。

DNS01

ここで、私の k8s クラスターはイントラネット内にあり、Ingress は第 2 層のメタルを使用しているため、証明書を申請するには DNS01 などの ACME 検証方法のみを使用できます。

当社のドメイン名解決サービスは Alibaba Cloud を使用しているため、公式リンクから alidns-webhook を見つけ、公式の手順に従って証明書を正常に申請しました。

alidns-webhook をインストールします。

 # alidns-webhook を cert-manager 名前空間にインストールします。
  kubectl apply -f https://raw.githubusercontent.com/pragkent/alidns-webhook/master/deploy/bundle.yaml

alidns 資格情報を含むシークレットを作成します:

ここで、base64 トランスコーディングを実行する必要があります。

 APIバージョン: v1
  種類: 秘密
 メタデータ:
  名前: alidns-secret
  名前空間: cert-manager
  データ：
  アクセスキー: YOUR_ACCESS_KEY
  秘密鍵: YOUR_SECRET_KEY

独自の Alibaba Cloud アカウントで Accesskey と AccessSecret を作成し、DNS ドメイン名の管理を承認したり、Alibaba Cloud に作業指示書を送信したりできます。

クラスター発行者:

 APIバージョン: cert-manager.io/v1alpha2
  種類: ClusterIssuer
  メタデータ:
  名前:letsencrypt-prod
  仕様:
  アクメ：
  # Letsencrypt のメールアドレスを変更する
 メールアドレス: [email protected]
  サーバー: https://acme-v02.api.letsencrypt.org/directory
  プライベートキーシークレットリファレンス:
  名前:letsencrypt-prod-account-key
  ソルバー:
  - dns01:
  ウェブフック:
  グループ名: acme.yourcompany.com
  ソルバー名: alidns
  設定:
  地域： ""
  アクセスキーシークレットリファレンス:
  名前: alidns-secret
  キー: アクセスキー
 シークレットキーシークレット参照:
  名前: alidns-secret
  キー: 秘密鍵

 PS: groupName を置き換える場合は、先頭の bundle.yaml ファイルで置き換える必要があります。

イングレスを構成する:

私のシステムには kuboard の Web UI がインストールされているので、ここで Ingress を作成できます。

kuboardのインストール方法:

 apiバージョン: extensions/v1beta1
  種類: イングレス
 メタデータ:
  名前: kuboard-dashboard
  名前空間: kube-system
  注釈:
  kubernetes.io/ingress.class: "nginx"
  cert-manager.io/cluster-issuer: "letsencrypt-prod"
  nginx.ingress.kubernetes.io/force-ssl-redirect: 'true' #HTTPS リダイレクトを強制する
 仕様:
  TLS: いいえ
 - ホスト:
  kuboard.it.example.cn より
 シークレット名: kuboard.it.example.cn-tls
  ルール:
  - ホスト: kuboard.it.example.cn
  http:
  パス:
  - パス：​​ /
  バックエンド:
  サービス名: kuboard
  サービスポート: 80

次のデバッグおよび検証コマンド:

 $ kubectl 証明書を取得する
 $ kubectl 証明書名を記述する
 $ kubectl シークレット名を記述する
 $ kubectl 注文名を記述する
 $ kubectl チャレンジ名を記述する

最後に、追記:イントラネット DNS サーバーが申請したドメイン名証明書を傍受したため、次のエラーが報告されました。

 E1202 04:05:41.696710 1 sync.go:182] cert-manager/controller/challenges "msg"="伝播チェックに失敗しました" "error"="\"kuboard.it.example.cn\" の DNS レコードはまだ伝播されていません" "dnsName"="kuboard.it.example.cn" "resource_kind"="チャレンジ" "resource_name"="kuboard.it.example.cn-tls-m5tmf-601210408-​​2135799246" "resource_namespace"="kube-system" "resource_version"="v1" "type"="DNS-01"