OCI Native Ingress Controllerを利用してHTTPS通信してみよう

# はじめに

前回OCI Native Ingress Controllerについて以下の記事を書きました。

https://qiita.com/takuya_0301/items/da616c9313eaeb9e8a9d

今回は前回の続きとして、OCI Native Ingress Controllerを利用したTLS接続について見ていきます。

# OCI Native Ingress ControllerでのTLS接続の利用

OCI Native Ingress Controllerでは以下の2つの方法でTLS通信、つまり証明書の管理ができます。

- Kubernetes Secretとして作成した証明書を利用
- OCI証明書サービスで作成した証明書を利用

今回は後者の方法を使います。

# 動作確認手順

## OCI証明書サービスでの証明書作成

OCI証明書サービスを利用した証明書の作成は、以下の記事が分かりやすいので、こちらを参考に作成してください。

https://qiita.com/Skogkatter112/items/da7847861c203fdab8ee

ここで作成した証明書のOCIDをメモしておいてください。

証明書のOCIDは証明書の詳細画面で確認できます。
今回は`test-ingress`という名前の証明書を作成しています。

![スクリーンショット 2023-06-05 13.15.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/40392/15dfca0a-d8ed-a319-0ffa-e3996a684409.png)

必要なものはこれだけです。


## Ingressへの証明書の登録

Ingressに証明書の情報を登録しましよう。

以下のようなManifestを作成します。

```yaml:ingress.yaml
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点です。

```yaml
  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を記載します。

```yaml
    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をデプロイします。

```sh
kubectl apply -f ingress.yaml
```

これでIngressへの証明書の登録は完了です。

## 動作確認

先ほどデプロイしたManifestの設定に沿ってLoadBalancerの設定変更が実施されます。

ここでは、その設定状況を見ていきましょう。

まずはリスナーの状況です。

今回はIngressに443ポートしか定義していないので、リスナーは一つだけです。
前回とは異なり、TLS設定がされています。（暗号スイートなど）

![スクリーンショット 2023-06-05 15.02.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/40392/1e28caae-11f7-d861-5c75-c5d5a5d2d065.png)

設定されている暗号スイートは以下の通りです。

![スクリーンショット 2023-06-05 15.03.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/40392/b74f1edf-4e09-0c5a-a068-0200904b7dba.png)

ルーティングポリシーはIngressに設定した通りになっています。(ホスト名とコンテキストパス)

![スクリーンショット 2023-06-05 15.03.43.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/40392/07b152fc-0104-d104-3b0d-d113b5b6ec2f.png)

バックエンドセットは以下の通りです。

![スクリーンショット 2023-06-05 15.08.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/40392/7df57d2f-5681-4748-c96b-06900a557b51.png)

リスナーに設定されるバックエンドセットとルーティングポリシーで設定されるバックエンドセットはそれぞれ設定されるようです。
また、デフォルトのバックエンドセットは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ロードバランサーを利用する場合はどんどん使っていきましょう！！