Quiz: Storing Secrets

쿠버네티스 Secret 의 값이 base64 로 되어 있는 이유는?

• 인코딩하면 값이 짧아져 etcd 용량을 줄일 수 있어서
• 고정 길이 문자열이라 RBAC 판정을 빠르게 할 수 있어서
• etcd 에 저장되기 전에 값을 암호화하기 위해
• 임의의 바이너리를 텍스트 필드에 안전하게 담기 위해

EncryptionConfiguration 의 providers 목록에서 identity 를 맨 앞에 두면?

• 우선순위가 가장 높은 자리라 가장 강한 암호화가 적용된다
• identity 는 마지막에만 올 수 있어 설정이 거부된다
• 쓰기에 identity 가 쓰여 평문 저장으로 되돌아간다
• 쓰기는 그대로 암호화되고 읽기만 평문으로 처리된다

저장 시 암호화를 켰는데 기존 Secret 이 여전히 평문으로 보입니다. 원인은?

• 값이 base64 로 감싸여 있어 암호문이 그대로 보이는 것이다
• apiserver 에 설정 파일이 반영되지 않아 암호화가 꺼져 있다
• 설정을 읽어 들이려면 etcd 를 재시작해야 하기 때문이다
• 암호화는 쓰기 시점에 적용되므로 기존 오브젝트를 한 번 다시 써야 한다

KMS 봉투 암호화의 구조로 옳은 것은?

• etcd 가 디스크에 쓰기 직전에 자체 키로 암호화한다
• kubelet 이 노드에서 마운트 직전에 복호화해 전달한다
• KMS 의 마스터 키로 모든 오브젝트를 직접 암호화한다
• 데이터는 데이터 키로, 데이터 키는 마스터 키로 암호화한다

Role 에 resourceNames: ["db-password"] 와 verbs: ["get", "list"] 를 함께 썼습니다. 결과는?

• resourceNames 와 list 를 같이 쓰면 Role 적용이 거부된다
• 이름 제한에 걸려 list 요청이 항상 403 으로 실패한다
• get 과 list 모두 db-password 하나로만 제한된다
• get 만 제한되고 list 는 네임스페이스의 모든 시크릿을 반환한다

immutable: true 인 Secret 의 값을 바꾸려면?

• patch 로 강제 수정한다
• immutable 을 false 로 되돌린 뒤 수정한다
• 새 이름의 Secret 을 만들고 참조를 옮긴다
• 네임스페이스를 다시 만든다

External Secrets 방식을 쓰면 사라지는 문제와 남는 문제는?

• 값이 클러스터 밖 볼트에만 있으므로 etcd 에 Secret 이 저장되는 일 자체가 사라진다
• 매니페스트에서도 클러스터에서도 값이 사라져 RBAC 와 저장 시 암호화 문제가 모두 없어진다
• 매니페스트에 값이 없어지지만, 오퍼레이터가 만든 클러스터 Secret 의 RBAC 와 저장 시 암호화 문제는 남는다
• 오퍼레이터가 볼트 권한을 대신 들고 있으므로 클러스터 RBAC 설계가 필요 없어진다

시크릿이 깃에 커밋된 것을 발견했습니다. 첫 번째로 할 일은?

• 저장소를 비공개로 전환해 노출 범위를 좁힌다
• 커밋한 사람과 시점을 확인해 영향 범위를 파악한다
• 해당 자격증명을 즉시 폐기하고 새 값으로 교체한다
• git filter-repo 로 히스토리에서 값을 지운다