보안과 직결된 보안 프로퍼티를 따로 관리할 필요가 있었습니다. 처음엔 원본 파일을 애플리케이션에 직접 저장하지 않고 EC2 내에 저장 후 이를 주입 받았었습니다. 하지만 해당 방식은 유지보수성 및 안정성에 문제가 있었습니다. 매번 동료 개발자가 보안 프로퍼티 수정을 위해 EC2를 접속해야 하는 불편함이 존재하고, EC2를 확장하기도 어려운 방법이였습니다.장점부터 살펴보죠. Github actions secret은 기존 Github actions의 CI workflow를 사용하기 때문에 새로운 툴 도입이 필요가 없습니다. 빠르게 구현할 수 있다는 장점이 있죠. 또한 무료입니다. 구현하기도 간편한데 무료면 더할 나위 없는 이점일겁니다.
단점을 살펴보죠. Github actions secret는 단일 디렉토리입니다. 아래 그림에서 보시다 싶이 책임을 분리하기가 어렵죠. AWS_ACCESS_KEY는 인증 & 인가 정보이지만 만약에 JWT_TOKEN_SECRET과 같은 보안 정보가 같은 Repository secrets에 있으면 유지보수하기 점점 어려워질겁니다. 현재는 보안 정보가 4-5개 밖에 없어서 괜찮을 수 있지만 프로젝트가 점점 커져서 200-300개가 된다면 Github actions secret는 유지보수하기에 정말 안좋은 툴이될겁니다.
무엇보다 Github Actions의 CI/CD 내 역할을 고려해봐야합니다. Github Actions의 CI/CD 내 역할이 무엇일까요? Github Actions가 스프링 애플리케이션의 보안 프로퍼티를 모두 책임 질 위치인가요? 아래 그림에서 볼 수 있듯이 Github Actions는 CI/CD 흐름 제어 역할을 합니다. Github Repo와 소통하여 데이터를 가져온 후, S3에 결과물을 전달하고 CodeDeploy에 배포 요청을 하죠. Github Actions의 역할은 다른 서버와 인터페이스로 소통하는 겁니다. 스프링 애플리케이션의 보안 프로퍼티 저장과는 결이 맞지 않죠.그렇다면 Github Actions에는 어떤 정보를 저장해야할까요? 바로 다른 서버와 소통할 때 사용되는 인증 & 인가 정보입니다. <그림5>를 보면 Github Actions Secrets는 다른 서버의 인증 및 인가 정보만 저장하고 있습니다. 여기서 누군가 궁금해할 수 있습니다!
Q. <그림4>를 보면 Github Actions는 AWS SecretsManager, AWS S3와 AWS CodeDeploy에게 요청을 보내는데 왜 <그림5>의 인증 및 인가 정보는 하나 밖에 없나요?