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 の致命的な誤用の可能性を比較的低く抑えます。