はじめに
前回OCI Native Ingress Controllerについて以下の記事を書きました。
今回は前回の続きとして、OCI Native Ingress Controllerを利用したTLS接続について見ていきます。
OCI Native Ingress ControllerでのTLS接続の利用
OCI Native Ingress Controllerでは以下の2つの方法でTLS通信、つまり証明書の管理ができます。
- Kubernetes Secretとして作成した証明書を利用
- OCI証明書サービスで作成した証明書を利用
今回は後者の方法を使います。
動作確認手順
OCI証明書サービスでの証明書作成
OCI証明書サービスを利用した証明書の作成は、以下の記事が分かりやすいので、こちらを参考に作成してください。
ここで作成した証明書のOCIDをメモしておいてください。
証明書のOCIDは証明書の詳細画面で確認できます。
今回はtest-ingressという名前の証明書を作成しています。
必要なものはこれだけです。
Ingressへの証明書の登録
Ingressに証明書の情報を登録しましよう。
以下のようなManifestを作成します。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: simple-fanout-example
namespace: native-ingress
annotations:
oci-native-ingress.oraclecloud.com/healthcheck-port: "80"
oci-native-ingress.oraclecloud.com/certificate-ocid: "ocid1.certificate.oc1.eu-frankfurt-1.amaaaaaassl6ssssssssssssslkrl3ambia"
spec:
ingressClassName: native-ic-ingress-class
rules:
- host: "tniita-demo-work.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: nginx1
port:
number: 443
前回の記事との違いは以下の2点です。
annotations:
oci-native-ingress.oraclecloud.com/healthcheck-port: "80"
oci-native-ingress.oraclecloud.com/certificate-ocid: "ocid1.certificate.oc1.eu-frankfurt-1.amaaaaaassl6ssssssssssssslkrl3ambia"
oci-native-ingress.oraclecloud.com/certificate-ocidというアノテーションフィールドに先ほどメモしたOCIDを記載します。
rules:
- host: "tniita-demo-work.com"
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: nginx1
port:
number: 443
前回の記事ではパスベースのルーティングで定義しましたが、今回はTLS接続を試すのでホスト名の設定を定義しています。
今回はtniita-demo-work.comを利用します。
TLS通信なので、ポート番号は443（このままリスナーポートになります)、バックエンドのサービスは前回の記事で作成したnginx1とします。
このManifestをデプロイします。
kubectl apply -f ingress.yaml
これでIngressへの証明書の登録は完了です。
動作確認
先ほどデプロイしたManifestの設定に沿ってLoadBalancerの設定変更が実施されます。
ここでは、その設定状況を見ていきましょう。
まずはリスナーの状況です。
今回はIngressに443ポートしか定義していないので、リスナーは一つだけです。
前回とは異なり、TLS設定がされています。（暗号スイートなど）
設定されている暗号スイートは以下の通りです。
ルーティングポリシーはIngressに設定した通りになっています。(ホスト名とコンテキストパス)
バックエンドセットは以下の通りです。
リスナーに設定されるバックエンドセットとルーティングポリシーで設定されるバックエンドセットはそれぞれ設定されるようです。
また、デフォルトのバックエンドセットはManifestの設定有無に限らずに設定されるようです。
（今回はManifestに設定していないので、バックエンドはありません）
補足としてはOCI Native Ingress ControllerでHTTPS通信を行う際には、バックエンドサービスまでのTLS通信となるので、考慮が必要です。（TLS終端がLoadBalancerにはなりません)
この点についてはドキュメントにも明記されています。
HTTPSトラフィックを処理する場合、OCIネイティブ・イングレス・コントローラによって作成されたOCIロード・バランサは、エンドツーエンドTLSを実装します。ロード・バランサは証明書を使用してクライアントからのTLS暗号化リクエストを受け入れ、ルーティング・ルールを使用してリクエストを適切なバックエンド・セットに転送します。バックエンド・セットは、(CAバンドルを新しい接続の信頼権限として使用して)クラスタで実行されているサービス・ポッドとの新しいTLS接続を作成します。
OCI証明書で管理されている証明書は前回の記事でインストールしたcert-managerで自動的にローテーションされます。
まとめ
OCI Native Ingress Controllerを利用するとOCI LoadBalancerとOCI証明書サービスとをシームレスに連携しながら運用することができます。
2回にわたってNative Ingress Controllerを紹介してきましたが、OKEでL7ロードバランサーを利用する場合はどんどん使っていきましょう！！