1. Homepage
  2. Flex Gateway (1.10)
  3. Flex Gateway の設定
  4. ローカルモードでの Flex Gateway の設定

  5. TLS コンテキストの設定

ローカルモードでの Flex Gateway の TLS コンテキストの設定

Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。ローカルモードの Flex Gateway をランタイムとして使用して API インスタンスを作成するときに TLS を使用するには、​PolicyBinding​ YAML 設定ファイルで TLS コンテキストを設定する必要があります。

TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。

Flex Gateway では以下がサポートされます。

  • クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる)

  • API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる)

  • インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS)

デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​Flex Gateway でサポートされる暗号化​を参照してください。暗号化を見つけるには、​Flex Gateway でサポートされる暗号化​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。

次のチュートリアルは、設定済みの ​PolicyBinding​ リソースの適用方法を示しています。リソースの設定方法については、ポリシー設定のページを参照してください。

インバウンド TLS の場合は、ポリシーリソースを API インスタンスにバインドします。アウトバウンド TLS の場合は、ポリシーリソースをアップストリームサービスにバインドします。

Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の TLS コンテキストを設定できます。

20%

25%

20%

Linux サービスとして Flex Gateway の TLS コンテキストを設定する

Docker コンテナで Flex Gateway の TLS コンテキストを設定する

Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する

始める前に

Flex Gateway の TLS コンテキストを設定する前に、次のタスクを完了する必要があります。

Linux サービスとして Flex Gateway の TLS コンテキストを設定する

  1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。

    sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml

  2. TLS コンテキスト設定の詳細を使用してファイルを更新します。次に例を示します。

    sudo vi /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml

    次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。

    • Transport Layer Security ポリシー - インバウンド

    • Transport Layer Security ポリシー - アウトバウンド

      特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:

      apiVersion: gateway.mulesoft.com/v1alpha1
kind: PolicyBinding
metadata:
  name: ingress-https-tls
spec:
  targetRef:
    kind: ApiInstance
    name: ingress-https
  policyRef:
    name: tls
  config:
    certificate:
      key: |
        # -----BEGIN PRIVATE KEY-----
        # insert certificate key
        # -----END PRIVATE KEY-----
      crt: |
        # -----BEGIN CERTIFICATE-----
        # insert certificate
        # -----END CERTIFICATE-----
    alpn:
      - http/1.1
      - h2
    minversion: "1.1"
    maxversion: "1.3"
    ciphers:
      - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      - TLS_CHACHA20_POLY1305_SHA256
      - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
      - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
      - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
      - TLS_RSA_WITH_AES_128_GCM_SHA256
      - TLS_RSA_WITH_AES_128_CBC_SHA
      - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
      - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
      - TLS_RSA_WITH_AES_256_GCM_SHA384
      - TLS_RSA_WITH_AES_256_CBC_SHA

      セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

  3. ポリシーが正しく適用されていることを確認します。

    次のサンプル ​curl​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。

    curl https://<SERVER_DOMAIN>:<SERVER_PORT>/get --cacert <SERVER_CERT_FILE> -v

    コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​200​ が返されることを確認してください。

    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server did not agree to a protocol
...
> HTTP/1.1 200 OK

    インバウンド mTLS の場合、次の例の ​curl​ コマンドは、ベースパスが ​/​である API プロキシを要求します。

    curl https://<SERVER_DOMAIN>:<SERVER_PORT>/get \
--cert <CLIENTAPP_CERT_FILE> \
--key <CLIENTAPP_KEY_FILE> \
--cacert <SERVER_CERT_FILE> \
--resolve <SERVER_DOMAIN>:<SERVER_PORT>:127.0.0.1 -v

    設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

    curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Docker コンテナで Flex Gateway の TLS コンテキストを設定する

Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。

  1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。

  2. Flex Gateway 設定ファイルを含むディレクトリに ​app​ という名前のフォルダーを作成します。

  3. 新しい ​app​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。

    docker run --rm \
-v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \
-p 8080:8080 \
mulesoft/flex-gateway
    -e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。

  4. YAML 設定ファイルを作成し、TLS コンテキストの詳細を使用して ​app​ フォルダーに保存します。

    次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。

    • Transport Layer Security ポリシー - インバウンド

    • Transport Layer Security ポリシー - アウトバウンド

      特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:

      apiVersion: gateway.mulesoft.com/v1alpha1
kind: PolicyBinding
metadata:
  name: ingress-https-tls
spec:
  targetRef:
    kind: ApiInstance
    name: ingress-https
  policyRef:
    name: tls
  config:
    certificate:
      key: |
        # -----BEGIN PRIVATE KEY-----
        # insert certificate key
        # -----END PRIVATE KEY-----
      crt: |
        # -----BEGIN CERTIFICATE-----
        # insert certificate
        # -----END CERTIFICATE-----
    alpn:
      - http/1.1
      - h2
    minversion: "1.1"
    maxversion: "1.3"
    ciphers:
      - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      - TLS_CHACHA20_POLY1305_SHA256
      - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
      - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
      - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
      - TLS_RSA_WITH_AES_128_GCM_SHA256
      - TLS_RSA_WITH_AES_128_CBC_SHA
      - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
      - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
      - TLS_RSA_WITH_AES_256_GCM_SHA384
      - TLS_RSA_WITH_AES_256_CBC_SHA

      セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

  5. ポリシーが正しく適用されていることを確認します。

    次のサンプル ​curl​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。

    curl https://<SERVER_DOMAIN>:<SERVER_PORT>/get --cacert <SERVER_CERT_FILE> -v

    コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​200​ が返されることを確認してください。

    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server did not agree to a protocol
...
> HTTP/1.1 200 OK

    インバウンド mTLS の場合、次の例の ​curl​ コマンドは、ベースパスが ​/​である API プロキシを要求します。

    curl https://<SERVER_DOMAIN>:<SERVER_PORT>/get \
--cert <CLIENTAPP_CERT_FILE> \
--key <CLIENTAPP_KEY_FILE> \
--cacert <SERVER_CERT_FILE> \
--resolve <SERVER_DOMAIN>:<SERVER_PORT>:127.0.0.1 -v

    設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

    curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する

Flex Gateway の TLS コンテキストを設定するには、YAML 設定ファイルと TLS コンテキストの詳細を使用して新しいリソースを作成します。

次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。

  • Transport Layer Security ポリシー - インバウンド

  • Transport Layer Security ポリシー - アウトバウンド

    特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:

    apiVersion: gateway.mulesoft.com/v1alpha1
kind: PolicyBinding
metadata:
  name: ingress-https-tls
spec:
  targetRef:
    kind: ApiInstance
    name: ingress-https
  policyRef:
    name: tls
  config:
    certificate:
      key: |
        # -----BEGIN PRIVATE KEY-----
        # insert certificate key
        # -----END PRIVATE KEY-----
      crt: |
        # -----BEGIN CERTIFICATE-----
        # insert certificate
        # -----END CERTIFICATE-----
    alpn:
      - http/1.1
      - h2
    minversion: "1.1"
    maxversion: "1.3"
    ciphers:
      - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      - TLS_CHACHA20_POLY1305_SHA256
      - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
      - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
      - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
      - TLS_RSA_WITH_AES_128_GCM_SHA256
      - TLS_RSA_WITH_AES_128_CBC_SHA
      - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
      - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
      - TLS_RSA_WITH_AES_256_GCM_SHA384
      - TLS_RSA_WITH_AES_256_CBC_SHA

    セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

Flex Gateway での TLS 暗号化のサポート

Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。

TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。

TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。

TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。

アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。

Flex Gateway でサポートされる暗号化

Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。

暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱

関連情報