배포는 애플리케이션 또는 소프트웨어의 새 버전을 사용자에게 릴리스하는 과정입니다. 이 과정은 애플리케이션 빌드, 테스트, 그리고 프로덕션에 배포하는 단계를 포함합니다. 이제, 배포 프로세스에는 풀 기반과 푸시 기반의 두 가지 접근 방식이 있습니다. 이번 글에서는 이 두 가지 접근 방식을 자세히 살펴보겠습니다.
푸시 기반 배포 방식
풀 배포 방식은 모든 변경 사항이 Kubernetes 클러스터 내부에서 적용된다는 개념에 기반합니다. 이는 클러스터 내에 배치된 오퍼레이터를 통해 이루어지며, 해당 오퍼레이터는 관련 Git 저장소와 Docker 레지스트리를 정기적으로 스캔하여 변경 사항을 감지합니다. 변경 사항이 감지되면 오퍼레이터는 클러스터의 데이터를 적절하게 업데이트합니다.
푸시 기반 배포 방식을 선택하면, 클러스터 자격 증명을 외부에 노출하고 CI 시스템에 저장해야 합니다. 이는 외부 시스템, 예를 들어 CD 파이프라인이 변경 사항을 프로덕션 환경으로 푸시하기 위해 클러스터에 대한 직접적인 접근이 필요하기 때문입니다. 하지만 클러스터 자격 증명을 외부에 노출하는 것은 보안 위험을 초래할 수 있습니다.
보안 권장 사항
이러한 자격 증명을 보호하기 위해 푸시 기반 배포 방식에선 다음과 같은 보안 관행을 따르는 것이 중요합니다:
- 암호화: 자격 증명을 암호화하여 저장하고 전송 중에도 암호화를 유지합니다.
- 접근 제어: 접근할 수 있는 사람을 제한하고, 최소 권한 원칙을 준수합니다.
- 자격 증명 회전: 자격 증명을 자주 교체하여 위험을 줄입니다.
풀 기반 배포 방식
풀 배포 방식은 모든 변경 사항이 Kubernetes 클러스터 내부에서 적용된다는 개념에 기반합니다. 이는 클러스터 내에 배치된 오퍼레이터를 통해 이루어지며, 해당 오퍼레이터는 관련 Git 저장소와 Docker 레지스트리를 정기적으로 스캔하여 변경 사항을 감지합니다. 변경 사항이 감지되면 오퍼레이터는 클러스터의 데이터를 적절하게 업데이트합니다.
풀 방식의 주요 이점 중 하나는 고유한 보안성입니다. 외부 클라이언트가 클러스터에 관리자 수준의 접근 권한을 가지지 않으므로, 무단 접근 또는 악의적인 공격의 위험이 줄어듭니다. 대신, 모든 변경 사항은 클러스터 내부에서 이루어져서 민감한 자격 증명 노출을 최소화하고 공격 표면을 줄입니다. (물론, 툴에 따라 외부 클러스터에 접근하여 CD 수행하는 옵션을 제공하긴 함)
마치며
푸시 기반과 풀 기반 배포 방식에는 각각의 장단점이 있습니다. 푸시 기반은 외부에서 직접 클러스터로 배포할 수 있는 유연성을 제공하지만, 보안상 자격 증명 노출 위험이 있습니다. 반면에 풀 기반은 클러스터 내부에서 모든 작업이 이루어지므로 보안이 강화되지만, 설정 및 운영에 더 많은 노력이 필요할 수 있습니다.
