day-log

Access Key를 GitHub Secrets에 박아두는 거, 이제 진짜 그만할 때가 됐다. 우리 팀도 작년에 한 번 키가 외부로 새서 식겁한 적이 있는데, 그 사건 이후로 모든 리포지토리를 OIDC로 옮겼다. 사실 옮기는 작업 자체가 어렵진 않다. 어려운 건 신뢰 정책(trust policy)을 너무 느슨하게 잡거나, 반대로 너무 빡빡하게 잡아서 워크플로우가 자꾸 깨지는 거다.이번 글에선 GitHub Actions의 OIDC 토큰으로 AWS IAM Role을 assume하는 과정을 실전 기준으로 정리한다. 처음 세팅하는 사람도 따라할 수 있게 단계별로 적었다.왜 OIDC인가장기 credential(Access Key/Secret Key)을 Secrets에 저장하면 두 가지가 걸린다. 하나는 키가 유출..

이번 주에 우리 팀 IAM trust policy 점검하다가 좀 놀란 게 있어서 짧게 적어둔다. 이거 모르는 분 꽤 많을 것 같다.익숙한 그 패턴GitHub Actions에서 AWS 붙일 때 OIDC federation 쓰는 건 이제 거의 표준이다. 그런데 trust policy 보다 보면 이런 게 자주 나온다.{ "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*" } }}좋다, 우리 repo로 한정은 했다. 근데 *이 너무 넓다. PR에서 돌아가는 워크플로우든, 누가 임시로 만든 브랜치에서 돌리는 거든, 환경 보호 없는 워크플로우든 — 전부 이 role을 가..

오늘 알게 된 건데, 의외로 모르는 분 꽤 많더라. External Secrets Operator(ESO) 쓰면서 ClusterSecretStore를 그냥 kind: ClusterSecretStore만 박아두고 끝내는 경우. 그러면 클러스터 안의 모든 네임스페이스가 그 SecretStore를 참조할 수 있게 된다. 즉, Vault나 AWS Secrets Manager로 가는 인증 경로가 사실상 클러스터 전체에 열려 있는 셈이다.ESO 공식 문서의 보안 베스트 프랙티스에서도 ClusterSecretStore와 ClusterExternalSecret는 cluster-scoped라 특히 조심하라고 강조한다. 근데 막상 helm chart로 깔고 나면 example manifest를 그대로 복붙해서 쓰니까 이 ..

지난주 화요일 아침, 팀 슬랙의 #security-alert 채널을 열었더니 빨간 메시지가 화면을 가득 채우고 있었다. 멘탈이 잠깐 나갔다. CI 파이프라인에 Trivy 스캔을 새로 붙인 첫날이었고, 우리가 운영하는 서비스 47개 중 31개가 한 번에 fail 처리됐다. 보고된 CVE만 1,400개가 넘었다.당연히 본부장이 디엠을 보냈다. "이거 다 수정해야 하나요?"솔직히 말하면 그 순간엔 답을 못 했다. 이 글은 그 1,400개의 알림 폭탄을 정리하면서 우리 팀이 어떻게 신호와 소음을 분리했는지에 대한 회고다. 결론부터 말하면, 진짜로 손대야 했던 건 23개였다.처음에 뭐가 잘못됐나일단 우리가 한 게 뭐였냐면, trivy image 기본 옵션으로 모든 이미지를 스캔하고 결과를 그대로 슬랙에 던진 거였..

쿠버네티스에서 시크릿을 어떻게 가져올 것이냐. 이 질문은 보통 회사가 어느 정도 커지고 클러스터가 두세 개 늘어나는 시점에 한 번 크게 부딪힌다. 우리 팀도 그랬다. 작년 초까지는 그냥 kubectl create secret으로 박아 넣고 헬름 차트에 손으로 옮기는 식이었는데, 클러스터가 4개로 늘고 환경별로 시크릿 동기화 누락이 두 번쯤 사고로 이어지면서 더는 못 미루겠다는 결론이 났다.후보는 사실상 두 개였다. External Secrets Operator(이하 ESO)와 HashiCorp의 Vault Agent Injector. 둘 다 충분히 성숙했고 사례도 많다. 그런데 막상 비교하기 시작하면 "어느 게 더 좋은가" 자체가 잘못된 질문이라는 게 금방 드러난다. 결국 우리 팀이 어떤 시크릿을 다루고..