퀴즈: Secret 보관

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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