Quiz: GitOps Security and Operations

Sealed Secrets 와 External Secrets Operator 의 차이로 옳은 것은?

• Sealed Secrets 는 암호문을 Git 에 두고 클러스터 컨트롤러가 복호화하며, ESO 는 외부 저장소 참조만 Git 에 두고 값은 오퍼레이터가 가져온다
• 둘 다 값을 Git 에 평문으로 두지만 접근 권한만 다르다
• Sealed Secrets 는 외부 볼트가 필수이고 ESO 는 필요 없다
• ESO 는 값을 Git 에 암호화해 저장하고 Sealed Secrets 는 참조만 저장한다

'ExternalSecret 매니페스트는 커밋해도 안전하다' 는 말에 반드시 덧붙여야 할 단서는?

• 오퍼레이터가 값을 실제 Secret 으로 만들어 내므로 RBAC 과 저장 시 암호화 문제는 그대로 남는다
• 그 매니페스트는 어차피 암호화되어 있으므로 추가 조치가 필요 없다
• ExternalSecret 을 쓰면 etcd 에 아무것도 저장되지 않는다
• ExternalSecret 은 Argo CD 가 지원하지 않으므로 Flux 로만 써야 한다

etcd 백업에서 Secret 값이 그대로 드러났다. 가장 먼저 점검할 클러스터 설정은?

• Secret data 필드의 base64 인코딩 옵션
• kubelet 의 이미지 자격증명 공급자 설정
• kube-apiserver 의 EncryptionConfiguration 과 providers 순서
• 네임스페이스 RoleBinding 의 get secrets 권한

시크릿이 이미 Git 에 커밋된 것을 발견했을 때 가장 먼저 해야 할 일은?

• 해당 자격증명을 즉시 폐기하고 새 값으로 교체한다
• git filter-repo 로 히스토리에서 값을 제거하고 강제 푸시한다
• 저장소를 비공개로 전환한다
• 커밋을 revert 하는 새 커밋을 만든다

AppProject 의 signatureKeys 를 설정했을 때 얻는 보호는?

• Git 저장소에 대한 푸시를 서버에서 거부한다
• 등록된 키로 서명이 검증된 커밋에서만 동기화하므로, 저장소가 뚫려 임의 커밋이 들어와도 적용되지 않는다
• Argo CD UI 로그인에 다중 인증(MFA)을 강제하게 된다
• 클러스터 자격증명을 자동으로 교체한다

argocd cluster add 를 기본 옵션으로 실행했을 때의 보안상 함정은?

• 대상 클러스터의 kubeconfig 가 Git 에 커밋된다
• Argo CD 의 admin 비밀번호가 초기화된다
• 대상 클러스터의 네트워크 정책이 모두 삭제된다
• 대상 클러스터에 만들어지는 ServiceAccount 가 cluster-admin 으로 바인딩된다

클라우드 네이티브 보안 4C 모델에 대한 설명으로 옳은 것은?

• Code → Container → Cluster → Cloud 순서로 안에서 바깥으로 보호가 전파된다
• 네 계층은 독립적이라 어느 하나만 잘해도 충분하다
• GitOps 를 도입하면 네 계층이 모두 자동으로 충족된다
• Cloud → Cluster → Container → Code 순서이며, 바깥 계층이 취약하면 안쪽 계층으로 만회할 수 없다