Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

34.3. 暗号化設定について

すべての利用可能なプロバイダーを含む暗号化設定ファイル

kind: EncryptionConfig
apiVersion: v1
resources: 1
  - resources: 2
    - secrets
    providers: 3
    - aescbc: 4
        keys:
        - name: key1 5
          secret: c2VjcmV0IGlzIHNlY3VyZQ== 6
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - secretbox:
        keys:
        - name: key1
          secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
    - aesgcm:
        keys:
        - name: key1
          secret: c2VjcmV0IGlzIHNlY3VyZQ==
        - name: key2
          secret: dGhpcyBpcyBwYXNzd29yZA==
    - identity: {}

1
resources のそれぞれの配列項目は分離した設定であり、詳細な設定が含まれます。
2
resources.resources フィールドは暗号化が必要な Kubernetes リソース名 (resource または resource.group) の配列です。
3
providers 配列は、順序付けられた 使用可能な暗号化プロバイダーの一覧 です。エントリーごとに 1 つのプロバイダータイプ (identity または aescbc) のみを指定できますが、同じ項目に両方を指定することはできません。
4
一覧の最初のプロバイダーがストレージに移動するリソースを暗号化するために使用されます。
5
シークレットの任意の名前です。
6
Base64 のエンコーディングされたランダムキーです。異なるプロバイダーが異なるキーの長さを指定します。詳細は、キーの生成方法 の説明を参照してください。

ストレージからのリソースの読み取り時に、保存されたデータに一致する各プロバイダーはデータの復号化を順番に試行します。情報またはシークレットキーの不一致により保存データを読み取れるプロバイダーがない場合にエラーが返され、クライアントがそのリソースにアクセスできなくなります。

重要

リソースが暗号化設定で読み取れない場合 (キーの変更により)、キーを基礎となる etcd ディレクトリーから削除することのみが必要になります。そのリソースの読み取りを試行する呼び出しは、キーが削除されるか、または有効な復号化キーが提供されない限り失敗します。

34.3.1. 利用可能なプロバイダー

名前暗号化強度速度キーの長さ他の考慮事項

identity

なし

該当なし

該当なし

該当なし

暗号化なしのそのままの状態で作成されたリソースです。最初のプロバイダーとして設定される場合、リソースは新規の値が書き込まれるときに復号化されます。

aescbc

PKCS#7 パディングが設定された AES-CBC

最も強い

高速

32 バイト

暗号化に推奨されるオプションですが、secretbox よりも若干遅くなる可能性があります。

secretbox

XSalsa20 および Poly1305

強い

より高速

32 バイト

より新しい標準であり、高レベルのレビューが必要な環境では受け入れ可能と見なされない可能性があります。

aesgcm

AES-GCM およびランダム初期化ベクター (IV)

200,000 回の書き込みごとにローテーションが必要です。

最速

16、24、または 32 バイト

自動化されたキーの回転スキームが実行される場合以外には、使用することが推奨されません

各プロバイダーは複数のキーをサポートします。キーは復号化の順序で試行されます。プロバイダーが最初のプロバイダーの場合、最初のキーが暗号化に使用されます。

注記

Kubernetes には適切な nonce ジェネレーターがないため、AES-GCM の nonce としてランダム IV を使用します。AES-GCM では適切な nonce がセキュアな状態であることが求められるため、AES-GCM は推奨されません。200,000 回の書き込み制限は nonce の致命的な誤用の可能性を比較的低く抑えます。