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
- 각
리소스배열 항목은 별도의 구성이며 전체 구성이 포함됩니다. - 2
resources.resources필드는 암호화해야 하는 Kubernetes 리소스 이름(리소스또는resource.group)의 배열입니다.- 3
- provider 배열은 가능한 암호화
프로바이더의 순서가 지정된 목록입니다. 항목별로 하나의 공급자 유형만 지정할 수 있습니다(ID또는aescbc를 제공할 수 있지만 둘 다 동일한 항목에서는 지정할 수는 없음). - 4
- 목록의 첫 번째 프로바이더는 스토리지로 이동하는 리소스를 암호화하는 데 사용됩니다.
- 5
- 시크릿의 임의 이름입니다.
- 6
- base64로 인코딩된 임의 키입니다. 서로 다른 공급자는 서로 다른 키 길이를 갖습니다. 키를 생성하는 방법에 대한 지침을 참조하십시오.
스토리지의 리소스를 읽을 때 저장된 데이터와 일치하는 각 공급자는 순서대로 데이터의 암호를 해독하려고 합니다. 형식 또는 시크릿 키에 불일치하여 저장된 데이터를 읽을 수 없는 경우 클라이언트가 해당 리소스에 액세스할 수 없도록 오류가 반환됩니다.
키가 변경되었기 때문에 암호화 구성을 통해 리소스를 읽을 수 없는 경우 기본 etcd에서 해당 키를 직접 삭제하는 것이 유일한 방법입니다. 해당 리소스 읽기를 시도하는 호출은 삭제되거나 유효한 암호 해독 키가 제공될 때까지 실패합니다.
34.3.1. 사용 가능한 공급자
| 이름 | Encryption | 강력함 | 속도 | 키 길이 | 기타 고려 사항 |
|---|---|---|---|---|---|
| identity | 없음 | 해당 없음 | 해당 없음 | 해당 없음 | 암호화 없이 작성된 리소스. 첫 번째 프로바이더로 설정하면 새 값이 작성될 때 리소스의 암호가 해독됩니다. |
| aescbc | PKCS#7 패딩 포함 AES-CBC | 강력함 | 신속 (Fast) | 32바이트 | 권장되는 암호화 선택이지만 secretbox 보다 약간 느릴 수 있습니다. |
| secretbox | XSalsa20 및 Poly1305 | 강력함 | 빠름 | 32바이트 | 높은 수준의 검토가 필요한 환경에서는 최신 표준으로 간주되지 않을 수 있습니다. |
| aesgcm | 임의의 초기화 벡터(IV)가 있는 AES-GCM | 200,000개의 쓰기마다 순환해야 합니다. | 가장 빠른 | 16, 24 또는 32바이트 | 자동 키 순환 체계를 구현하는 경우를 제외하고는 를 사용하지 않는 것이 좋습니다. |
각 공급자는 여러 개의 키를 지원합니다. 암호 해독을 위해 키가 시도됩니다. 공급자가 첫 번째 공급자인 경우 첫 번째 키는 암호화에 사용됩니다.
Kubernetes에는 적절한 nonce 생성기가 없으며 AES-GCM에 대해 임의 IV를 nonce로 사용합니다. AES-GCM은 안전한 의사가 필요하므로 AES-GCM은 권장되지 않습니다. 20만 건의 쓰기 제한은 치명적인 오류 발생 가능성을 합리적인 낮은 마진으로 제한합니다.
