배경
멘토 피드백에서 취업 포트폴리오를 위해 팀 인프라 레포(
kintoun-infra)를 public으로 전환하는 게 권장되었다. 다만 이 레포는 실제 AWS 계정과 연동된 Terraform 코드이기 때문에, 공개 전 민감정보 유무를 먼저 검토하기로 했다.검토 과정
1) .gitignore 확인
.tfstate,.terraform/,.tfvars(단,example.tfvars는 예외),tfplan등 민감할 수 있는 파일들이 이미 제외 목록에 등록되어 있음을 확인했다.
2) 레포 내 민감 패턴 검색
아래 키워드를 레포 전체 검색으로 확인했고, 전부 검색 결과 없음(0건)이었다.
AKIA(AWS Access Key 접두사)
secret_access_key
password
- 실제 AWS 계정 ID
.tfstate(파일명)
3) 폴더별 파일 목록 확인
bootstrap/, identity/, platform/, modules/ 각 폴더를 확인한 결과, 실제 값이 담긴 .tfvars나 .pem 같은 파일은 없었고 템플릿 성격의 example.tfvars만 존재했다.4) identity 모듈 설계 문서 확인
README에 다루는 범위와 다루지 않는 범위가 명시되어 있었다.
- 다루는 것: IAM User 생성·삭제, 그룹 소속, MFA 강제 정책
- 다루지 않는 것: 콘솔 로그인 비밀번호, 액세스 키 발급(대신
aws login임시자격증명 사용)
즉 설계 단계부터 장기 자격증명(액세스 키)을 아예 발급하지 않는 구조였다.
5) platform 아키텍처 문서 확인
VPC 대역(10.50.0.0/16 등 사설 IP)과 보안그룹 구성도가 포함되어 있었으나, 사설 IP 대역은 공개되어도 실질적 위험이 없고 보안그룹도 "인바운드 없음 + SSM 경유 접속"으로 구성되어 있어 문제 없음을 확인했다.
6) GitHub Actions 워크플로우 파일 확인
terraform-apply.yml, terraform-plan.yml 2개 파일을 확인했다.aws-actions/configure-aws-credentials@v4+role-to-assume: ${{ vars.AWS_APPLY_ROLE_ARN }}방식 → 정적 액세스 키 없이 OIDC(단기 토큰) 방식으로 인증
terraform-plan.yml에는 conftest(OPA 정책 검증), IAM 가드레일 자동 검사, PR 자동 코멘트까지 구성되어 있음
- 두 파일 모두 하드코딩된 키·비밀번호 없음
검토 결과 요약
항목 | 결과 |
코드·설정 파일 내 하드코딩된 자격증명 | 없음 |
.gitignore의 state·tfvars 제외 처리 | 양호 |
인증 방식(OIDC, 장기 키 미사용) | 모범적 |
아키텍처 문서 내 민감정보(사설 IP만 노출) | 무해 |
Actions 실행 로그 내 ARN 노출 여부 | 확인 필요 (미확인) |
git 커밋 히스토리 전체 스캔 | 미확인 (추후 진행) |
결론: 조건부 공개 가능. 파일·코드 수준에서는 민감정보가 없다는 것을 확인했지만, 아래 두 가지를 확인·조치한 뒤 public 전환하는 것을 권장한다.
왜 이 두 가지가 중요한가
1. Actions 실행 로그의 ARN 노출
워크플로우에서
AWS_APPLY_ROLE_ARN, AWS_PLAN_ROLE_ARN 값은 Secrets가 아니라 Variables로 저장되어 있다. GitHub은 Secrets는 로그에 출력될 때 자동으로 *** 마스킹 처리하지만, Variables는 마스킹되지 않는다. 즉 파일 자체에는 값이 없더라도, 워크플로우가 실행될 때마다 로그에 역할 ARN(계정 ID 포함)이 평문으로 기록되어 있을 수 있다.IAM Role ARN의 구조 :
arn:aws:iam::123456789012:role/MyApplyRole - AWS 공식 가이드상 계정 ID나 역할 이름을 민감 정보로 취급하지는 않지만 신중하게 사용하고 공유해야 한다는 점에서 생각해볼 여지 존재.
레포를 public으로 전환하면 코드뿐 아니라 과거에 쌓인 Actions 실행 기록 전체도 함께 공개된다. 파일 검색(grep)만으로는 절대 잡을 수 없는 부분이라, 별도로 Actions 탭에 들어가 과거 실행 로그를 직접 열어
Configure AWS credentials 스텝에 실제 ARN 값이 찍혀 있는지 확인해야 한다. 노출이 확인되면 해당 값을 Secrets로 이전하거나 과거 로그를 삭제하는 절차가 필요하다.2. 커밋 히스토리 전체 스캔
지금까지의 검토는 현재 시점의 파일 상태만 확인한 것이다. 하지만 git은 삭제된 값도 히스토리에 그대로 남긴다. 예를 들어 과거 어느 시점에 실수로 액세스 키나 실제
.tfvars를 커밋했다가 나중에 지웠더라도, git log나 과거 커밋 diff를 통해 여전히 조회가 가능하다.이번 프로젝트 자체가 다루는 시나리오(하드코딩된 자격증명이 GitHub 공개 저장소를 통해 유출되는 공격 경로)를 떠올리면, 같은 실수를 우리 레포에서 반복하지 않도록 공개 전
gitleaks나 trufflehog 같은 도구로 전체 히스토리를 한 번 스캔하는 것이 안전하다. 현재 파일 상태가 깨끗하다는 것과, 히스토리 전체가 깨끗하다는 것은 다른 문제이기 때문이다.
