ホストヘッダーへのサーバーポートの追加

デフォルトでは、Traefik は Host ヘッダーを、ほとんどの最新アプリと互換性のある方法で処理します。 Host ヘッダーにポートを含めるよう変更することは推奨されません。 変更を加える前に、Traefik がデフォルトでヘッダーをどのように処理しているかを確認し、上書きが適切な場合を把握しておいてください。

Host ヘッダーのデフォルト処理

Host Traefik は、デフォルトで passHostHeader: true。 Host ヘッダーにポート番号を埋め込む代わりに、以下の個別の転送ヘッダーを自動的に追加します：

• X-Forwarded-Host

• X-Forwarded-Port

レガシーアプリにおける Host ヘッダーの上書き

アプリで Host ヘッダーに埋め込まれたポートが必要になる場合は、Traefik のHeadersミドルウェアを使用して上書きしてください。

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      Host: "legacy-app.example:8080"

Traefik Ingress アノテーションを使用して、Ingress リソースにミドルウェアを適用します。 CRD 処理が有効になっていることを確認してください（デフォルトでは有効になっています）。 CRDの処理を設定するには、「 ibm-ingress-deploy-config 」の「 ConfigMap 」フィールドの「 processTraefikCRDs 」を参照してください。

プライベートALBを使用した着信リクエストのルーティング

デフォルトでは、パブリックALBはIngressリソースを処理します。 代わりに、着信リクエストをプライベートALB経由でルーティングするには、 Ingressリソース の「 spec.ingressClassName 」フィールドに「 private-iks-traefik 」クラスを指定してください。

spec.ingressClassName: "private-iks-traefik"

アプリを認証するには App ID

Traefik Ingress を設定して IBM Cloud App ID を使用して、アプリへの認証を強制するように設定します。 詳細については、「 アプリへの App ID 認証の追加 」を参照してください。

クライアントのリクエスト本文の最大サイズの設定

デフォルトでは、Traefik はクライアントのリクエスト本文のサイズに制限を設けていません。 上限を設定するには、バッファリング・ミドルウェアを作成し、それをIngressリソースに適用します。

Traefikは、設定された制限を超えるリクエストをすべて、 HTTP 413レスポンスで拒否します。

1. Traefik のバッファリングミドルウェアリソースを作成します。 maxRequestBodyBytes を、クライアントが送信できる最大バイト数に設定します。 次の例では、上限を 2 MB（2097152 バイト）に設定しています。

   # Example (Kubernetes Middleware)
   apiVersion: traefik.io/v1alpha1
   kind: Middleware
   metadata:
     name: limit
   spec:
     buffering:
       maxRequestBodyBytes: 2097152
   

2. Traefik Ingress アノテーションを使用して、Ingress リソースにミドルウェアを適用します。

クライアントの応答データのバッファリングを有効にする

デフォルトでは、Traefik はバッファリングを行わずにレスポンスを直接ストリーミングします。 バッファリング・ミドルウェアを使用することで、Traefikはレスポンスをメモリに保存したり、ディスクに書き込んだりしてから、クライアントに送信することができます。 レスポンスのバッファリングは、ほとんどの場合推奨されないため、このミドルウェアはアプリで必要とされる場合にのみ使用してください。

レスポンスのバッファリングを有効にするには、以下の手順を実行してください

1. Traefik のバッファリングミドルウェアリソースを作成します。 maxResponseBodyBytes を最大レスポンスサイズ（バイト単位）に設定し、 memResponseBodyBytes を、その値を超えるとレスポンスがメモリに保持されずディスクに書き込まれるしきい値に設定します。 次の例では、合計で最大 5 MB をバッファリングし、そのうち最初の 1 MB をメモリに保持します。

   # Example (Kubernetes Middleware)
   apiVersion: traefik.io/v1alpha1
   kind: Middleware
   metadata:
     name: response-buffer
   spec:
     buffering:
       maxResponseBodyBytes: 5242880    # 5 MB max response size
       memResponseBodyBytes: 1048576    # 1 MB in memory, then disk
   

2. Traefik Ingress アノテーションを使用して、Ingress リソースにミドルウェアを適用します。

タイムアウトの設定

Traefik には、2 種類のタイムアウト制御機能があります。1 つはクライアントと ALB 間のタイムアウト、もう 1 つは ALB とバックエンドアプリ間のタイムアウトです。 ボトルネックがどこにあるかによって、それぞれ個別に設定してください。

クライアントからALBへのタイムアウトを設定するには、 ibm-ingress-deploy-config の ConfigMap フィールドを 次のように設定します：

• HTTP または HTTPS へのリクエストが、Traefik インスタンスからの応答を待機する時間を設定するには、 httpReadTimeout および httpsReadTimeout フィールド を使用します。
• レスポンスの書き込みタイムアウトまでの最大時間を設定するには、 httpWriteTimeout および httpsWriteTimeout フィールド を使用します。
• キープアライブ接続が閉じられるまでの最大継続時間を設定するには、「 httpIdleTimeout 」および「 httpsIdleTimeout 」フィールドを使用します。

ALBとバックエンドアプリ間の接続タイムアウトおよび読み取りタイムアウトを設定するには、 ServersTransport を使用して、Traefikと HTTP サーバー間のトランスポートを設定してください。

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: mytransport
spec:
  forwardingTimeouts:
    dialTimeout: 30s
    responseHeaderTimeout: 10s
    idleConnTimeout: 90s

VPC クラスターの場合は、パブリック ALB を公開しているロードバランサーサービスのアイドル接続タイムアウトも変更する必要があります。 CLUSTER_ID を、ご自身のクラスタ ID に置き換えてください。クラスタ ID は、 ibmcloud ks cluster get --cluster CLUSTER_NAME_OR_ID を実行することで取得できます。 次の例では、タイムアウトを910秒に設定しています：

kubectl annotate svc -n kube-system public-cr<clusterid> service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout="910"

Traefikでは、タイムアウトに「 0 」という値を指定することで、タイムアウトを無効にすることができます。

VPCロードバランサーの ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout アノテーションは、値がゼロの場合をサポートしていません。 タイムアウト値は、50秒から7200秒（2時間）の間で設定できます。 2時間を超える時間が必要な場合は、 サポートチケット を開き、業務上の理由をご提示ください。

クラスタが、Webアプリケーションファイアウォール（WAF）またはグローバルロードバランシングが有効になっている IBM Cloud Internet Services (CIS) またはCloudflareを介して公開されている場合は、これらのタイムアウトを900秒より長く設定してください。 詳細については、 Cloudflareのドキュメント をご覧ください。

ServersTransport リソースを作成したら、Traefikの Serviceアノテーションを使用して、そのリソースをServiceリソースに適用します。

エラー時の処理のカスタマイズ

特定の HTTP エラーに対してALBが実行できるカスタムアクションを指定するには、Traefik のエラーミドルウェアを設定してください。 ミドルウェアを作成したら、Traefik Ingress アノテーションを使用して、それを Ingress リソースに適用します。

HTTP および HTTPS のデフォルトポートの変更

デフォルトでは、ALBは HTTP に対してポート80で、 HTTPS に対してポート443でリスニングします。 クラスターで標準以外のポートが必要な場合は、 ibm-ingress-deploy-config （ ConfigMap ）の 「 httpPort 」および「 httpsPort 」フィールド を使用して、ALBごとにこれらの値を変更できます。

リクエストヘッダーのカスタマイズ

Traefik のヘッダーミドルウェアを使用すると、クライアントからのリクエストをバックエンドアプリに転送する前に、そのリクエストのヘッダーフィールドを追加、上書き、または削除することができます。 これは、スクリプト名、テナント識別子、またはアプリが必要とするその他のメタデータといったコンテキストを注入するのに役立ちます。

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customRequestHeaders:
      X-Script-Name: "test"

ミドルウェアを作成したら、Traefik Ingress アノテーションを使用して、それを Ingress リソースに適用します。

レスポンスヘッダーのカスタマイズ

Traefik のヘッダーミドルウェアを使用すると、レスポンスをクライアントに送信する前に、ヘッダーフィールドを追加、上書き、または削除することができます。 これは、セキュリティポリシーの適用、 CORS ヘッダーの追加、あるいはクライアントに到達する前に内部ヘッダーを削除する際に役立ちます。

# Example (Kubernetes Middleware)
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-header
spec:
  headers:
    customResponseHeaders:
      X-Custom-Response-Header: "value"

ミドルウェアを作成したら、Traefik Ingress アノテーションを使用して、それを Ingress リソースに適用します。

セキュリティ対策が不十分なリクエストのリダイレクト

HTTPS httpsRedirect へのアクセスのみを強制し、 へのすべての着信リクエストを エンドポイントに恒久的にリダイレクトするには、 HTTP HTTPS ibm-ingress-deploy-config ConfigMap 内のxml-ph-0003@deepl.internalフィールドを設定します。

HTTP の「Strict Transport Security」の有効化と無効化

HTTP 「Strict Transport Security（ HSTS ）」は、ブラウザに対し、ドメインへのアクセスは HTTPS 経由でのみ行うよう指示し、プロトコルダウングレード攻撃を防止します。 この機能は、Traefik ではオプトイン方式となっています。 「 Headers」ミドルウェアを使用し、 stsSeconds、 stsIncludeSubdomains、 stsPreload の各フィールドを設定することで、この機能を有効にします。

# Example (Kubernetes Middleware) - produces: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: security-headers
spec:
  headers:
    stsSeconds: 31536000            # max-age=1 year
    stsIncludeSubdomains: true
    stsPreload: true

以下の Traefik Ingress アノテーションを使用して、Ingress リソースにミドルウェアを適用します。

ALBによるリクエストURIの照合方法の変更

デフォルトでは、Traefikはリクエストをルーティングするために PathPrefix マッチャーを使用します。 アプリで正確なパス一致や正規表現に基づくルーティングが必要な場合は、以下の Traefik Ingress アノテーションを使用して、マッチャーを上書きしてください。

traefik.ingress.kubernetes.io/router.pathmatcher: PathRegexp

相互認証の構成

相互認証（ TLS ）（ mTLS ）では、サーバーとクライアントの両方が有効な証明書を提示する必要があり、標準の TLS よりも強力な認証を実現します。 ALB でクライアント証明書による認証を必須にするには、CA 証明書のシークレットを参照する TLSOption リソースを作成してください。

# Example (Kubernetes TLSOption)
apiVersion: traefik.io/v1alpha1
kind: TLSOption
metadata:
  name: mtls
  namespace: default
spec:
  minVersion: VersionTLS12
  clientAuth:
    secretNames:
      - my-ca-secret
    clientAuthType: RequireAndVerifyClientCert

TLSOption リソースを作成したら、Traefik Ingressアノテーションを使用して、そのリソースをIngressリソースに適用します。

アップストリームリクエストのリトライ動作の設定

バックエンドサーバーが応答しない場合、Traefikは自動的に別のアップストリームサーバーに対してリクエストを再試行することができます。 Traefik のRetryミドルウェアを使用して、再試行の動作を設定します。 ミドルウェアを作成したら、Traefik Ingress アノテーションを使用して、それを Ingress リソースに適用します。

速度制限

レート制限は、一定時間内にALBが処理するリクエスト数を上限に設定することで、バックエンドアプリケーションをトラフィックの急増や不正利用から保護します。 Traefikの RateLimit ミドルウェアを使用して、レート制限を設定します。 ミドルウェアを作成したら、Traefik Ingress アノテーションを使用して、それを Ingress リソースに適用します。

パスの書き換え

パス書き換え機能を使用すると、バックエンドアプリがリスニングしているパスとは異なる、 URL というパスを公開することができます。 たとえば、 /app に到着したリクエストを、 / でリクエストを待機しているバックエンドアプリに転送することができます。 固定置換が必要か、パターンに基づく置換が必要かによって、以下の Traefik リソースのいずれかを使用してください：

• Traefikの ReplacePath ミドルウェアリソース
• Traefikの ReplacePathRegex ミドルウェアリソース

# Example Replace the path with /foo
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepath
spec:
  replacePath:
    path: "/foo"

# Example Replace path with regex
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: test-replacepathregex
spec:
  replacePathRegex:
    regex: "^/foo/(.*)"
    replacement: "/bar/$1"

以下の Traefik Ingress アノテーションを使用して、Ingress リソースにミドルウェアを適用します。

スティッキークッキーを用いたトラフィックのルーティング

スティッキーセッションにより、セッションが継続している間は、クライアントからのリクエストが常に同じバックエンドサーバーにルーティングされるようになります。 これは、セッションデータをサーバー上にローカルで保存するステートフルなアプリにおいて有用です。 Ingress リソースで Traefik Service のスティッキークッキーアノテーションを設定し、スティッキーセッションを有効にしてください。

アプリとALB間のトラフィックの暗号化

デフォルトでは、Traefik はプレーンな HTTP 経由でバックエンドアプリにトラフィックを転送します。 アプリで暗号化されたアップストリーム接続が必要な場合は、 ServersTransport リソースを使用して、ALBとアプリ間の TLS を設定し、CA証明書や想定されるサーバー名などを指定してください。

# Example (Kubernetes ServersTransport)
apiVersion: traefik.io/v1alpha1
kind: ServersTransport
metadata:
  name: backend-transport
spec:
  rootCAs:
    - secret: my-ca-cert
  serverName: <myapp.example.com> # must match your certificate

以下の Traefik Service アノテーションを使用して、 ServersTransport を Service リソースに適用します。

ALB デプロイメントのカスタマイズ

ibm-ingress-deploy-config （ ConfigMap ）は、レプリカ数、ポート、ログレベル、タイムアウト値、IngressプロバイダーなどのALBレベルの設定を制御します。 この ConfigMap を使用すると、個々のIngressリソースを変更することなく、クラスタ内の1つまたは複数のALBに構成変更を適用できます。

1. 各 ALB を公開するサービスの名前を取得します。 サービス名をメモしておいてください。後の手順でこれらを使用します。

   • クラシック・クラスター:

       kubectl get svc -n kube-system | grep alb
       ```
   * VPC クラスター: 出力で、`public-crc204dl7w0qf6n6sp7tug` のようなフォーマットのサービス名を探します。
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

2. ibm-ingress-deploy-config 構成マップの YAML ファイルを作成します。 ALB ID ごとに、以下のオプション設定を 1 つ以上指定できます。 設定したい項目だけを指定すれば十分です。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ibm-ingress-deploy-config
     namespace: kube-system
   data:
     <alb1-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
     <alb2-id>: '{"replicas":<number_of_replicas>, "ingressClass":"<class>", "httpsPort":"<port>", "httpPort":"<port>", "logLevel": "<TRACE|DEBUG|INFO|WARN|ERROR|FATAL|PANIC>", "ingressProvider": "<ingress|ingress-nginx>", "processTraefikCRDs": <true|false>, "traefikIngressNginxAllowExternalNameServices": <true|false>, "traefikCRDAllowCrossNamespace": <true|false>, "traefikCRDAllowExternalNameServices": <true|false>, "httpReadTimeout": <seconds>, "httpWriteTimeout": <seconds>, "httpIdleTimeout": <seconds>, "httpsReadTimeout": <seconds>, "httpsWriteTimeout": <seconds>, "httpsIdleTimeout": <seconds>, "httpsRedirect": <true|false>, "customEntryPoints": {"<name>": {"port": <port>, "protocol": "<TCP|UDP>", "readTimeout": <seconds|0>, "writeTimeout": <seconds|0>, "idleTimeout": <seconds|0>, "udpTimeout": <seconds>}}, "tolerations": [{"key":"<key>","operator":"<Equal|Exists>","value":"<value>","effect":"<NoSchedule|PreferNoSchedule|NoExecute>"}]}'
   

   replicas

   デフォルトでは、各ALBには2つのレプリカがあります。 ALB ポッド数を増やすことで、ALB の処理能力をスケールアップします。 詳しくは、ALB ポッドのレプリカ数を増やすを参照してください。

   ingressClass

   Ingressリソースで public-iks-traefik または private-iks-traefik 以外のクラスを指定した場合は、ここにクラス名を入力してください。

   httpPort, httpsPort

   開きたい HTTP ポートまたは HTTPS ポートを追加することによって、Ingress ALB のデフォルト以外のポートを公開します。

   デフォルト値：80/443。

   logLevel

   ロギングレベルを指定します。 以下のサイトからお選びください： TRACE、 DEBUG、 INFO、 WARN、 ERROR、 FATAL、 PANIC。

   デフォルト： INFO。

   ingressProvider

   この ALB で使用する Traefik Ingress プロバイダーを指定してください。 有効値:

   ingress: Traefik独自のIngressコントローラー を使用します。 Ingressリソース上のTraefik固有のアノテーションを処理します。

   ingress-nginx: 一時的な Traefik における Ingress 用互換性レイヤー -NGINX を使用します。 このツールは、Ingress（ NGINX ）用に作成されたアノテーションを処理し、可能な限りIngress（ NGINX ）の動作を再現します。 この値を利用して、Ingress（ NGINX ）からTraefikへの移行を行ってください。

   デフォルト： ingress。

   processTraefikCRDs

   true に設定すると、TraefikはIngressリソースに加えて、独自のCRDリソースも処理します。 サポートされているCRDには、 IngressRoute、 Middleware、および TLSOption が含まれます。 完全なリストについては、 TraefikのCRDに関するドキュメントを参照してください。

   デフォルト： true。

   traefikIngressNginxAllowExternalNameServices

   ingress-nginx プロバイダーによって処理されるIngressオブジェクトに対して、 ExternalName サービスのサポートを有効にします。 このオプションは、 ingressProvider が ingress-nginx に設定されている場合にのみ適用されます。

   デフォルト： true。

   traefikCRDAllowCrossNamespace

   IngressRoute のリソース（Traefik CRD）が、他のネームスペースにあるリソースを参照できるようにします。

   デフォルト: false。

   traefikCRDAllowExternalNameServices

   IngressRoute リソース（Traefik CRD）が、 ExternalName サービスを参照できるようにします。

   デフォルト: false。

   httpReadTimeout, httpsReadTimeout

   ALBとクライアント間の HTTP ／ HTTPS の読み取りタイムアウトを設定します。 値は秒単位の整数でなければなりません。0に設定すると、タイムアウトが無効になります。

   詳細については、 Traefikのドキュメントを参照してください。

   httpWriteTimeout, httpsWriteTimeout

   ALBとクライアント間の HTTP ／ HTTPS の書き込みタイムアウトを設定します。 値は秒単位の整数でなければなりません。0に設定すると、タイムアウトが無効になります。

   詳細については、 Traefikのドキュメントを参照してください。

   httpIdleTimeout, httpsIdleTimeout

   ALBとクライアント間の HTTP ／ HTTPS のアイドルタイムアウト（キープアライブ）を設定します。 値は秒単位の整数でなければなりません。0に設定すると、タイムアウトが無効になります。

   詳細については、 Traefikのドキュメントを参照してください。

   IBM Cloud Internet Services (CIS) またはCloudflareのWebアプリケーションファイアウォール（WAF）やグローバルロードバランシングを使用する場合は、この値を900秒より長く設定してください。 詳細については、「 タイムアウトの設定 」を参照してください。

   httpsRedirect

   すべての HTTP への着信リクエストを、 HTTPS エンドポイントへ恒久的にリダイレクトするように設定します。

   デフォルト: false。

   customEntryPoints

   Traefik 用の追加のカスタムエントリポイントを指定します。 エントリポイントの名前が、そのオブジェクトのキーとなります。 以下のエントリポイント名は予約済みであり、使用することはできません： web、 websecure、 traefik、 hc、 http 、および https。

   エントリポイントの設定が無効な場合、カスタムエントリポイントは一切処理されません！

   customEntryPoints.<name>.port

   使用するエントリポイントのポート。 このフィールドは必須です。 他のポートと競合しないことを確認してください。

   ここで定義されたポートおよびプロトコルは、ロードバランサー上で手動で公開する必要があります。手順については以下をご覧ください。

   customEntryPoints.<name>.protocol

   使用するエントリポイントのプロトコル。 このフィールドは必須です。 有効な値は TCP および UDP です。

   customEntryPoints.<name>.readTimeout

   ALBとクライアント間のエントリポイントの読み取りタイムアウトを設定します。 値は秒単位の整数でなければなりません。0に設定すると、タイムアウトが無効になります。

   詳細については、 Traefikのドキュメントを参照してください。

   customEntryPoints.<name>.writeTimeout

   ALBとクライアント間のエントリポイントの書き込みタイムアウトを設定します。 値は秒単位の整数でなければなりません。0に設定すると、タイムアウトが無効になります。

   詳細については、 Traefikのドキュメントを参照してください。

   customEntryPoints.<name>.idleTimeout

   ALBとクライアント間のエントリポイントのアイドルタイムアウト（キープアライブ）を設定します。 値は秒単位の整数でなければなりません。0に設定すると、タイムアウトが無効になります。

   詳細については、 Traefikのドキュメントを参照してください。

   customEntryPoints.<name>.udpTimeout

   UDP リスナーのエントリポイントのアイドルタイムアウトを設定します。 このフィールドは、 UDP プロトコルを使用するエンドポイントについてのみ考慮されます。 値は秒単位の整数であり、かつ0より大きいものでなければなりません。

   詳細については、 Traefikのドキュメントを参照してください。

   tolerations

   ALB ポッドに対する追加のカスタム許容誤差を指定します。 詳細については、「 テイントとトレラレーション 」を参照してください。

3. クラスターに ibm-ingress-deploy-config 構成マップを作成します。

   kubectl create -f ibm-ingress-deploy-config.yaml
   

4. 変更を反映させるには、ALBを更新してください。 変更が反映されるまで、最大5分ほどかかる場合があります。 コマンドが出力を表示せずに終了した場合、更新は正常に送信されました。

   ibmcloud ks ingress alb update -c CLUSTER_NAME_OR_ID
   

5. 標準以外の HTTP や HTTPS のポートを指定した場合、または追加のエントリポイントを作成した場合は、各ALBサービスでそれらのポートを開く必要があります。

   1. ステップ 1 で見つけた各 ALB サービスについて、YAML ファイルを編集します。

       kubectl edit svc -n kube-system <alb_svc_name>
       ```
   2. `spec.ports` セクションで、開くポートを追加します。 デフォルトでは、ポート 80 と 443 が開きます。 80 と 443 を開いたままにする場合は、それらをこのファイルから削除しないでください。 指定しないポートは閉じられます。 `nodePort` を指定しないでください。 ポートを追加して変更を適用すると、`nodePort` は自動的に割り当てられます。
   
   ```sh {: codeblock}
       ...
       ports:
       - name: port-80
         port: 80
         protocol: TCP
         targetPort: 80
       - name: port-443
         port: 443
         protocol: TCP
         targetPort: 443
       - name: <new_port>
         port: <port>
         protocol: TCP
         targetPort: <port>
       ...
       ```
   3. ファイルを保存して閉じます。 変更が自動的に適用されます。
   
   

Ingress クラスのカスタマイズ

Ingress クラスは、クラス名を Ingress コントローラーのタイプに関連付けるもので、これにより、同じクラスター内に複数のコントローラーを共存させることができます。 この IngressClass リソースを使用して、ALB用のカスタムクラスを定義します。

Traefik は、 .spec.controller が traefik.io/ingress-controller に設定されている Ingress クラスについてのみ処理を行います。

アプリへの App ID 認証の追加

Ingress ALBと統合することで、 IBM Cloud App ID Ingress ALBと統合することで、アプリを未認証のアクセスから保護します。 認証が設定されている場合、ALBはリクエストを OAuth2-Proxy を経由して転送し、 が App ID で認証情報を検証してから、トラフィックをアプリに転送します。

1. 既存の App ID インスタンスを選択するか、新しいインスタンスを作成します。

   App ID インスタンスは、クラスター内の 1 つの名前空間のみで使用できます。 複数の名前空間で Ingress リソースの App ID を構成する場合は、このセクションのステップを繰り返して、各名前空間の Ingress リソースに対して固有の App ID インスタンスを指定します。

   • 既存のインスタンスを使用するには、サービスインスタンス名に小文字の英数字のみが含まれており、その長さが25文字を超えないことを確認してください。 名前を変更するには、サービス・インスタンスの詳細ページの「オプションを増やす 」メニューから**「サービスの名前変更」**を選択します。
   • 新しい App ID インスタンスをプロビジョンするには、以下のようにします。
     1. サービス名を、サービス・インスタンスの独自の固有名で置き換えます。 サービスインスタンス名には、小文字の英数字のみを含める必要があり、25文字を超えてはなりません。
     2. クラスターのデプロイ先と同じリージョンを選択します。
     3. 「作成」 をクリックします。

2. アプリのリダイレクト URL を追加します。 リダイレクト URL は、アプリのコールバック・エンドポイントです。 フィッシング攻撃を防止するために、IBM Cloud App ID は、要求 URL をリダイレクト URL の許可リストと照合します。

   1. App ID 管理コンソールで、**「認証の管理 (Manage Authentication)」**にナビゲートします。
   2. 「ID プロバイダータブで、ID プロバイダーが選択されていることを確認します。 IDプロバイダーが選択されていない場合、認証は行われませんが、アプリへの匿名アクセス用のアクセストークンが発行されます。
   3. 「認証設定 (Authentication settings)」 タブで、アプリのリダイレクト URL を形式 https://<hostname>/oauth2-<App_ID_service_instance_name>/callback で追加します。 サービスインスタンス名に含まれる文字はすべて小文字でなければなりません。

   IBM Cloud App ID のログアウト機能 を使用する場合は、ドメインの末尾に「 /sign_out 」を追加して「 https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out 」という形式にし、この「 URL 」をリダイレクト URL リストに含めてください。 カスタムログアウトページを使用するには、 OAuth2-Proxy ConfigMap 内の whitelist_domains を設定してください。 「 rd 」というクエリパラメータを指定して https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out エンドポイントを呼び出すか、 X-Auth-Request-Redirect ヘッダーにカスタムログアウトページ URL を設定してください。 詳細については、「 サインアウト 」を参照してください。

3. App ID サービス・インスタンスをクラスターにバインドします。 このコマンドは、サービスインスタンス用のサービスキーを作成します。また、 --key オプションを指定することで、既存のサービスキーの認証情報を使用することもできます。 サービスインスタンスを、Ingressリソースが存在する名前空間にバインドしてください。 サービスインスタンス名に含まれる文字はすべて小文字でなければなりません。

   ibmcloud ks cluster service bind --cluster CLUSTER_NAME_OR_ID --namespace NAMESPACE --service APP_ID_SERVICE_INSTANCE_NAME [--key SERVICE_INSTANCE_KEY]
   

   サービスがクラスターに正常にバインドされると、そのサービスインスタンスの認証情報を格納するクラスターシークレットが作成されます。 次に、出力例を示します。

   ibmcloud ks cluster service bind --cluster mycluster --namespace mynamespace --service appid1
   Binding service instance to namespace...
   OK
   Namespace:    mynamespace
   Secret name:  binding-<service_instance_name>
   

4. クラスターで ALB OAuth プロキシー・アドオンを有効にします。 このアドオンは、 Kubernetes の以下のリソースを作成および管理します。 App ID サービスインスタンス用の OAuth2-Proxy デプロイメント、 OAuth2-Proxy の設定を含むシークレット、および着信リクエストを OAuth2-Proxy デプロイメントにルーティングするIngressリソースです。 各リソースの名前は、 oauth2- で始まります。

   1. alb-oauth-proxyアドオンを有効にします。

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. ALB OAuth プロキシー・アドオンの状況が `Addon Ready` であることを確認します。 ステータスが「 `Enabling` 」と表示された場合は、数分待ってからコマンドを再実行してください。
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. App ID 認証を追加したいアプリのIngressリソースについては、リソース名が25文字を超えないようにしてください。 次に、 ForwardAuth ミドルウェアを設定します：

   1. Traefikの ForwardAuth ミドルウェアリソースを作成します。 address は、 App ID インスタンスの OAuth2-Proxy の URL を指定します。このインスタンスは、OIDCの信頼先（RP）として機能します。 サービスインスタンス名に含まれる文字はすべて小文字でなければなりません。

       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           tls:
             insecureSkipVerify: true
       ```
       デフォルトでは、Traefik は TLS の IP サブジェクト代替名（SAN）の妥当性を検証します。 IBM-提供された証明書はこの検証に失敗すると予想されるため、 `insecureSkipVerify: true` オプションを使用してください。 この設定により、TraefikインスタンスまたはALBが、 `oauth2-proxy` のデプロイインスタンスと通信できるようになります。
       {: note}
   
   2. アプリに `Authorization` ヘッダーで送信するトークンを選択します。 ID およびアクセストークンに関する詳細については、『 [App ID 』のドキュメント](/docs/appid?topic=appid-tokens) を参照してください。
       * `ID Token` のみを送信するには、 ForwardAuth ミドルウェアに `authResponseHeaders` オプションを追加してください：
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
       * `Access Token` のみを送信するには、 ForwardAuth ミドルウェアに `authResponseHeaders` オプションを追加してください：
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
               tls:
                 insecureSkipVerify: true
           ```
       * `Access Token` と `ID Token` の両方を送信するには、 ForwardAuth ミドルウェアに `authResponseHeaders` オプションを追加してください：
   
           ```yaml {: codeblock}
           apiVersion: traefik.io/v1alpha1
           kind: Middleware
           metadata:
             name: oauth-verify
             namespace: default
           spec:
             forwardAuth:
               address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
               authResponseHeaders:
                 - X-Auth-Request-Access-Token
                 - Authorization
               tls:
                 insecureSkipVerify: true
           ```
   3. オプション：アプリが [API戦略](/docs/appid?topic=appid-key-concepts#term-api-strategy) に加えて、またはその代わりに [Webアプリ戦略](/docs/appid?topic=appid-key-concepts#term-web-strategy) をサポートしている場合は、 ForwardAuth ミドルウェアに `authSigninURL` を追加してください。 サービスインスタンス名に含まれる文字はすべて小文字でなければなりません。
   
   ```yaml {: codeblock}
       apiVersion: traefik.io/v1alpha1
       kind: Middleware
       metadata:
         name: oauth-verify
         namespace: default
       spec:
         forwardAuth:
           address: "https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth"
           authResponseHeaders:
             - X-Auth-Request-Access-Token
             - Authorization
           authSigninURL: /oauth2-<App_ID_service_instance_name>/sign_in?rd={url}
           tls:
             insecureSkipVerify: true
       ```
       * `authSigninURL` を指定し、クライアントの認証に失敗した場合、クライアントは OAuth2-Proxy にリダイレクトされ、そこからさらに App ID のログインページにリダイレクトされます。
       * `authSigninURL` を指定しない場合、クライアントは有効なベアラートークンを使用して認証を行う必要があります。 認証に失敗した場合、リクエストは「 `401 Unauthorized` 」エラーで拒否されます。
   
   

6. オプション：設定上必要な場合は、Traefikの ServersTransport リソースを作成し、アプリの Service リソースに転送されるリクエストに対して、 TLS による検証をスキップするように設定してください。

   # Example (Kubernetes ServersTransport)
   apiVersion: traefik.io/v1alpha1
   kind: ServersTransport
   metadata:
     name: skip-tls-verify
   spec:
     insecureSkipVerify: true
   

   TraefikのService アノテーションを使用して、 ServersTransport をServiceリソースに適用します。

7. 作成した「 ForwardAuth 」ミドルウェアを適用して、 App ID 認証を強制するように、Ingress リソースを編集してください。 以下の Traefik Ingress アノテーションを使用してください。

   traefik.ingress.kubernetes.io/router.middlewares: "default-oauth-verify@kubernetescrd"
   

   適切なアノテーションが設定されたIngressリソースが再適用されると、ALBの OAuth プロキシアドオンは oauth2-proxy のデプロイメントを展開し、そのデプロイメント用のサービスを作成するとともに、 oauth2-proxy デプロイメントのルーティングを設定するための個別のIngressリソースを作成します。 これらのアドオン・リソースは削除しないでください。

8. App ID 認証がアプリに実施されていることを確認します。

   • アプリが Webアプリ戦略 に対応している場合：Webブラウザでアプリの URL にアクセスしてください。 App ID が正しく適用されていれば、App ID 認証ログイン・ページにリダイレクトされます。
   • アプリが API戦略 に対応している場合：アプリへのリクエストの「Authorization」ヘッダーに、 Bearer のアクセストークンを指定してください。 アクセス・トークンを取得するには、App ID の資料を参照してください。 App ID が正しく適用されている場合、要求は正常に認証され、アプリに経路指定されます。 Authorizationヘッダーにアクセストークンを含めずにアプリにリクエストを送信した場合、または App ID がアクセストークンを受け入れない場合、そのリクエストは拒否されます。

9. （任意）：クラスターでネットワークポリシーやその他のファイアウォールソリューションを使用して送信トラフィックを制限している場合は、クラスターからパブリックな App ID サービスにアクセスできることを確認してください。 このサービスのIPアドレス範囲を取得するには、 お客様 サポート を通じてリクエストを送信してください。

10. オプション: OAuth2-Proxy のデフォルト動作をカスタマイズするには、Kubernetes 構成マップを作成します。

    1. 変更する OAuth2-Proxy 設定の値を指定する構成マップ YAML ファイルを作成します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: oauth2-<App_ID_service_instance_name>
          namespace: <ingress_resource_namespace>
        data:
          auth_logging: <true|false>
          # Log all authentication attempts.
          auth_logging_format:
          # Format for authentication logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#logging-configuration
          cookie_csrf_expire: "15m"
          # Expiration time for CSRF cookie. Default is "15m".
          cookie_csrf_per_request: <true|false>
          # Enable multiple CSRF cookies per request, making it possible to have parallel requests. Default is "false".
          cookie_domains:
          # A list of optional domains to force cookies to. The longest domain that matches the request’s host is used. If there is no match for the request’s host, the shortest domain is used. Example: sub.domain.com,example.com
          cookie_expire: "168h0m0s"
          # Expiration time for cookies. Default: "168h0m0s".
          cookie_samesite: ""
          # SameSite attribute for cookies. Supported values: "lax", "strict", "none", or "".
          email_domains: ""
          # Authenticate IDs that use the specified email domain. To authenticate IDs that use any email domain, use "*". Default: "". Example: example.com,example2.com
          pass_access_token: <true|false>
          # Pass the OAuth access token to the back-end app via the X-Forwarded-Access-Token header.
          request_logging: <true|false>
          # Log all requests to the back-end app.
          request_logging_format:
          # Format for request logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#request-log-format
          scope:
          # Scope of the OAuth authentication. For more info, see https://oauth.net/2/scope/
          set_authorization_header: <true|false>
          # Set the Authorization Bearer response header when the app responds to the Ingress ALB, such as when using the Traefik ForwardAuth Middleware.
          set_xauthrequest: <true|false>
          # Set X-Auth-Request-User, X-Auth-Request-Email, and X-Auth-Request-Preferred-Username response headers when the app responds to the Ingress ALB, such as when using the Traefik ForwardAuth Middleware.
          standard_logging: <true|false>
          # Log standard runtime information.
          standard_logging_format:
          # Format for standard logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#standard-log-format
          tls_secret_name:
          # The name of a secret that contains the server-side TLS certificate and key to enable TLS between the OAuth2-Proxy and the Ingress ALB. By default, the TLS secret defined in your Ingress resources is used.
          whitelist_domains:
          # Allowed domains for redirection after authentication. Default: "". Example: example.com,*.example2.com For more info, see: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#command-line-options
          oidc_extra_audiences:
          # Additional audiences which are allowed to pass verification.
          cookie_refresh:
          # Refresh the cookie after this duration. Example: "15m". To use this feature, you must enable "Refresh token" for the AppID instance. For more info, see: /docs/appid?topic=appid-managing-idp&interface=ui#idp-token-lifetime
        ```
    2. 構成マップ・リソースをアドオンに適用します。 変更が自動的に適用されます。
    ```sh {: pre}
        kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
        ```
    

各ALB OAuth Proxyアドオンのバージョンごとの変更点のリストについては、「 IBM Cloud ALB OAuth Proxyアドオンの変更履歴 」を参照してください。

ALBの「 OAuth 」プロキシアドオンのアップグレード

ALB OAuth Proxy アドオンを新しいバージョンにアップグレードするには、現在のインストールを無効にしてから、目的のバージョンで再度有効にしてください。 アップグレード中、既存の oauth2-proxy インスタンスは中断されません。

アドオンが無効化されていても、監視対象の oauth2-proxy インスタンスはクラスタ上に残ったままとなるため、アップグレードプロセスはサービスを中断することなく行われます。

1. アドオンを無効にします。

   ibmcloud ks cluster addon disable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
   

2. 利用可能なアドオンのバージョンを一覧表示し、使用したいバージョンを明記してください。 出力には、利用可能なバージョンと、どのバージョンがデフォルトであるかが表示されます。

   ibmcloud ks cluster addon versions --addon alb-oauth-proxy
   

3. アドオンを有効にして、--version オプションを指定します。 バージョンを指定しないと、デフォルト・バージョンが有効になります。

   ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID [--version VERSION]
   

ソース IP アドレスの保持

デフォルトでは、Ingress ALB はクライアントリクエストの元の送信元 IP アドレスを保持しません。 これにより、IPアドレスに基づくアクセス制御、ログ記録、およびセキュリティポリシーが正しく機能しなくなる可能性があります。 ソースIPの保持を有効にするには、お使いのクラスターの種類に該当する方法を選択してください。

TLS のプロトコルと暗号方式の設定

TLSOption リソースを使用して、ALBに到達するトラフィックに対して、 TLS の最低バージョンを強制したり、暗号スイートを制限したり、その他の TLS 接続パラメータを設定したりできます。 TLSOption リソースを作成したら、Traefik Ingressアノテーションを使用して、そのリソースをIngressリソースに適用します。

既存のクライアントへのカスタム証明書の送信

Server Name Indication（SNI）に対応していないレガシーデバイスは、どの TLS 証明書を使用するかをネゴシエートできないため、カスタム証明書ではなく、ALBのデフォルトのLet's Encrypt証明書を受け取ることになります。 これらのデバイスがカスタム証明書を確実に受け取れるようにするには、ALBのデフォルトのサーバー設定を更新し、カスタム TLS シークレットを指定してください。

デフォルトで生成される「Let 's Encrypt」証明書は、実動で使用するためのものではありません。 実動ワークロードでは、独自のカスタム証明書を持ち込みます。

クラシッククラスターを作成すると、 IBM はデフォルトの Ingress シークレットに対して Let's Encrypt 証明書を提供します。 カスタムシークレットを作成し、Ingressリソースで TLS のターミネーションにそれを指定すると、ALBはLet's Encryptの証明書ではなく、そのカスタム証明書をクライアントに送信します。 ただし、クライアントがSNIに対応していない場合、ALBのデフォルトのサーバー設定にデフォルトのシークレットが指定されているため、ALBはデフォルトでLet's Encryptの証明書を使用します。 SNI非対応のデバイスにカスタム証明書を送信するには、以下の手順を実行してください。

1. alb-default-server Ingress リソースを編集します。

   kubectl edit ingress alb-default-server -n kube-system
   

2. spec.tls セクションで、hosts.secretName 設定の値を、カスタム証明書を格納するカスタム・シークレットの名前に変更します。

   spec:
     rules:
     ...
     tls:
     - hosts:
       - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
       secretName: <custom_secret_name>
   

3. リソース・ファイルを保存します。

4. リソースがカスタム・シークレット名を指すようになったことを確認します。 これらの変更は ALB に自動的に適用されます。 出力結果で、 spec.tls[].secretName がご自身のカスタムシークレット名と一致していることを確認してください。

   kubectl get ingress alb-default-server -n kube-system -o yaml
   

ALB のパフォーマンスの調整

ワーカーノードには、ほとんどのワークロードに適した最適化されたカーネルチューニングが自動的に適用されます。 クラスターに特定のハイスループットや低レイテンシの要件がある場合は、 ワーカーノードの Linux カーネル sysctl パラメータを調整することで、ALBのパフォーマンスをさらに最適化できます。 これらの設定は、パフォーマンスの最適化が明確に必要とされる場合にのみ変更してください。誤った値を設定すると、ノードの安定性が損なわれる可能性があります。

次のステップ

• Ingress ALB を管理して、クラスター内の ALB をスケーリング、更新、または無効化します。
• マネージド Ingress サービスを使用して、アプリを公開するように Ingress を設定します。
• Ingress をデバッグして、よくある Ingress の問題を診断・解決します。

関連リンク

• Traefikのドキュメント
• Traefik ミドルウェアのリファレンス
• Traefik CRD リファレンス
• IBM Cloud App ID の資料