블로그 릴레이 - AWS에서의 컨테이너 보안에 대해 1
2024.11.11안녕하세요 클래스메소드의 이수재입니다.
본 블로그는 당사의 한국어 블로그 릴레이의 스물한 번째 블로그입니다.
이번 블로그의 주제는「AWS에서의 컨테이너 보안에 대해」입니다.
AWS에서 컨테이너 환경을 운용하기 위해 ECS, EKS, ECR 등 다양한 서비스를 이용할 수 있습니다.
이번 글에서는 AWS 상의 컨테이너 보안에 대해 모범 사례나 도움이 되는 내용에 대하여 알아봅니다.
무엇을 확인해야하는가
컨테이너 보안에 대해서는 가이드라인이 되고 있는 애플리케이션 컨테이너 보안 가이드(NIST SP800-190)[1]라는 것이 있습니다.
해당 가이드라인에 따르면 컨테이너의 보안 리스크는 아래와 같이 분류되고 있습니다.
- 이미지에 대한 위험
- 레지스트리에 대한 위험
- 오케스트레이터에 대한 위험
- 호스트에 대한 위험
- 컨테이너에 대한 위험
이번 글에서도 위의 분류를 따라가며 각 위험에 대해 AWS에서는 어떻게 대응하는 것이 가능한지 알아봅니다.
AWS 에서의 컨테이너 환경 구성
컨테이너를 운영하는데 있어서는 복잡한 프로세스와 구성 요소가 있지만 이 글에서는 이미지의 저장, 오케스트레이터, 호스트에 대해서만 알아봅니다.
AWS에서는 이미지를 저장 및 배포하기 위해 ECR(Elastic Container Registry)이라는 서비스를 이용합니다.
ECR은 AWS가 관리하는 컨테이너 이미지 레지스트리 입니다.
docker를 사용할 때 이미지를 저장하는 dockerhub 등과 같습니다.
AWS에서 컨테이너를 운용하기 위한 오케스트레이터 서비스(컨트롤 플레인)로는 ECS나 EKS를 사용할 수 있습니다.
상세한 차이는 있지만 보통 쿠버네티스를 활용할 것인지를 기준으로 서비스를 선택합니다.
컨테이너를 호스팅하기 위한 컴퓨팅 리소스(데이터 플레인)로는 EC2나 Fargate를 선택할 수 있습니다.[2]
보통 OS레벨의 관리가 필요한지, 리소스의 스펙을 자유롭게 선택할 필요가 있는지, 리소스의 관리는 AWS에 맡겨도 문제없는지에 따라서 사용하는 서비스가 달라지는 경우가 많습니다.
컨테이너와 보안 책임 모델
AWS의 서비스를 이용할 때 보안에 대해서는 사용하는 유저와 AWS 가 함께 관리할 필요가 있습니다.
이를 공동 책임 모델 이라고 합니다.
특히 컴퓨팅 서비스를 이용하는 경우 이러한 부분이 더욱 부각됩니다.
예로 들면 EC2를 이용하는 경우 다음과 같은 책임 모델을 가지게 됩니다.
EC2 인스턴스의 에이전트 및 노드 구성을 관리하거나 네트워크와 데이터 등 많은 부분을 유저가 담당해야합니다.
하지만 Fargate를 이용하는 경우에는
AWS가 인스턴스의 관리와 사용되는 런타임에 대한 보안을 책임집니다.
따라서 환경을 운영할 때 이러한 부분까지 신경을 쓰기 힘들다면 Fargate를 도입하는 것이 좋을수도 있습니다.
이미지에 대한 위험
컨테이너 환경의 보안 강화를 위해서는 이미지에 대한 보안을 먼저 생각해두는 것이 좋습니다.
이미지를 보호하고 최적화 하는 방법에 대해서 몇 가지를 소개합니다.
아래 설명하는 내용 이외에 이미지에 관한 모범 사례는 아래 페이지도 참고해주세요.
최소(minimal) 혹은 distroless 이미지 사용
이미지에 불필요한 부분을 제거하여 이미지의 읽기 속도 및 보안 향상을 실현할 수 있습니다.
따라서 애플리케이션과 해당 런타임 종속성만 포함한 이미지(distroless)를 사용하거나 아무것도 없는 기본 이미지(scratch)에서 이미지를 작성할 수 있습니다.
distroless에 대해서는 아래 깃허브를 참고해주세요.
scratch에서 이미지를 만드는 방법에 대해서는 아래 문서를 참고해주세요.
이미지를 스캔하기
AWS ECR에서는 이미지를 스캔할 수 있으며 이미지를 푸시할 때 스캔하거나 원하는 시간에 스캔 하는 것이 가능합니다.
스캔에는 기본 스캔과 향상된 스캔이 있습니다.
기본 스캔은 이미지 스캔 솔루션인 Clair를 사용합니다.
고급 스캔은 Amazon Inspector를 사용하며 Amazon EventBridge와 연동하여 사용하는 것이 가능하기 때문에 위험도가 높은 이미지가 스캔되면 삭제하거나 알림을 생성하는 등 결과에 따른 액션을 자동화 할 수 있습니다.
또한 레지스트리 서비스 뿐만 아니라 로컬의 이미지에 대해서도 스캔할 수 있습니다.
예를 들어 Docker Desktop을 사용하는 경우 로컬 이미지를 스캔할 수 있습니다.
특수한 권한 제거
setuid 나 setgid 와 같은 권한을 가지고 있으면 권한을 에스컬레이션 하는데 사용할 수 있습니다.
따라서 이미지에서 모두 제거하는 것이 좋습니다.
ECR로 푸시된 이미지 암호화
ECR로 푸시된 이미지는 저장 시 KMS를 사용하여 자동으로 암호화됩니다.
대신 자체 키를 사용하고 싶은 경우 고객 관리형 키(CMK)를 사용하여 ECR로 푸시된 이미지를 암호화 할 수 있습니다.
ECR에 대한 수명 주기 정책 사용
시간이 지남에 따라 취약하고 오래된 소프트웨어 패키지가 있는 이미지는 배포 및 노출되는 것을 방지하기 위해 제거하는 것을 추천하고 있습니다.
ECR에서는 수명주기 정책을 설정할 수 있으므로 일정 기간이 지난 이미지는 삭제하도록 설정하는 것을 추천합니다.
기밀 정보는 외부에 저장하기
이미지 안에 기밀성이 높은 데이터(비밀번호, 개인키) 등을 평문으로 저장하는 것은 위험합니다.
AWS에서는 이러한 데이터를 저장,관리,사용하기 위해 System Manager Parameter Store 혹은 Secret Manager 기능을 제공하고 있습니다.
ECR에서 변경 불가능한 태그 기능 활성화
악의를 가진 유저는 손상된 버전의 컨테이너 이미지를 동일한 태그로 Amazon ECR 저장소에 푸시하는 방식으로 환경에 위협을 가할 수 있습니다.
이에 대한 해결책으로 이미지의 각 새 버전에 대해 새 태그를 강제로 적용하는 변경 불가능한 태그 기능 활성화하는 것입니다.
기능이 활성화되어있는 상황에서 이미 존재하는 태그의 이미지를 푸시하면 ImageTagAlreadyExistsException 오류가 반환됩니다.
아래 문서가 참고가 될 것이라 생각합니다.
큐레이션 이미지 세트 만들기
개발자가 자체 이미지를 만들고 사용하는 것이 아닌 조직에서 허용된 이미지의 모음(큐레이팅한 이미지 세트)를 만들고 해당 세트에서만 이미지를 사용할 수 있도록 하는 것이 좋습니다.
레지스트리에 대한 위험
이미지에는 민감한 내용(조직 자체에 대한 기밀성이 높은 내용, 소프트웨어의 구성 등)이 포함된 경우가 많습니다.
따라서 레지스트리 자체에 대한 액세스도 올바른 제한이 필요합니다.
위에서 설명했듯이 AWS에서는 이러한 레지스트리 서비스로 ECR을 제공하고 있으며 액세스는 IAM을 기반으로 하여 제어할 수 있습니다.
AWS에 로그인하기 위해 스스로를 인증하려면 AWS 루트 사용자 혹은 IAM 사용자, IAM 역할 등이 필요합니다.
이 중 루트 사용자로 AWS 서비스를 이용하는 것은 추천되지 않으니 IAM 사용자 혹은 IAM 역할이 인증을 위한 수단으로 많이 사용됩니다.
어떠한 주체인가를 통해 인증이 완료되었다면 각 주체의 권한은 IAM 정책을 통하여 관리합니다.
JSON 형식의 정책문을 이용하여 어떤 주체가 어떤 리소스에서 어떤 작업이 가능한지 설정할 수 있습니다.
IAM에 대한 내용은 다음 문서가 도움이 될 것이라 생각합니다.
마무리
글이 길어져서 2편으로 나누어 적게 되었습니다.
컨테이너의 보안에서 어떤 부분을 신경써야하는지 그리고 이미지와 레지스트리를 어떻게 관리하는 것이 중요한지 알아보았습니다.
다른 위협에 대해서는 다음 글에서 알아보도록 하겠습니다.
긴 글 읽어주셔서 감사합니다.
오탈자 및 내용 피드백은 must01940 지메일로 보내주시면 감사합니다.
