최근 몇 달동안 팀원 중 한명이 모든 노드에 보안 패키지를 설치하는 것을 여러번 하는 것을 봤습니다. 정확한 노드 개수는 모르나 몇 백대에서 몇천대인걸로 보였습니다. AWS 클라우드에 실행되는 노드는 SSM(Systems Manager)을 사용하여 작업을 진행하고 있어서, 개인적으로 어떻게 SSM으로 노드에 패키지를 설치하고 SSM의 동작원리가 궁금했습니다.
그래서 이번 기회에 AWS SSM의 대표적인 기능 몇개를 정리했습니다.
AWS SSM이란?
SSM(Systems Manager, 이하 SSM)은 중앙에서 AWS, on-premise, multi cloud의 인스턴스를 관리하는 서비스입니다.
모든 노드에 같은 설정을 해야할 때 일일이 모든 서버에 접속해서 작업하려면 많은 시간이 걸립니다. 그리고 휴먼 실수가 일어날 수 있어 작업이 제대로 진행안될 수 있습니다. 이런 불편함을 개선하기 위해 중앙에서 모든 노드를 관리하는 시스템이 노드 관리 시스템입니다. 노드 관리 시스템은 노드 식별, 명령어 실행, 원격 접속 등 중앙에서 모든 노드를 관리할 수 있습니다.
SSM은 AWS managed 노드 관리시스템입니다. EC2 인스턴스 뿐만 아니라 온프레미스, 멀티 클라우드의 노드까지 관리할 수 있습니다.
System Manager 아키텍처
SSM은 Agent기반 아키텍처입니다. 다시 말해서 SSM은 SSM agnet가 있는 노드만 관리할 수 있습니다. SSM과 SSM agent는 public으로 통신합니다. private 통신도 가능하지만 endpoint 등 네트워크 구축이 필요합니다.
SSM과 SSM agent는 직접 통신하지 않고 Amazon Message Gateway Service(ssmmessages)를 통해 비동기로 통신하는것으로 추측합니다. SSM agent가 inbound 필요없는 이유도 요청을 받는게 아니라 ssmmessages에서 요청을 가져오거나 상태 또는 명령어 실행 결과를 하기 때문입니다.
SSM agent가 ssmmessages에 접근 권한이 필요하기 때문에, EC2 인스턴스 IAM profile는 ssmmessages에 대한 policy를 가지고 있습니다.
System Manger 장점과 단점
장점
System Manager는 Managed service이기 때문에 사용하기만 하면 됩니다. 그리고 개인적으로 생각한 가장 큰 장점은 outbound 443/TCP만 방화벽을 허용하면 됩니다.
단점
아키텍처에서 말씀드린 것처럼 노드에 SSM agent가 필요합니다. 그리고 SSM과 통신하기 위해 public 네트워크가 필요합니다.
System Manager Agent 설치
SSM은 agent가 설치되어 있는 노드만 관리하기 때문에, 노드에 SSM agent를 꼭 설치해야 합니다.
설치방법
Amazon에서 관리하는 AMI는 System Manager Agent가 이미 설치되어 있습니다. 리눅스 기준으로 systemd로 관리됩니다.
SSM agent가 설치되어 있더라도 SSM을 바로 사용할 수 있는건 아닙니다. 2가지 사항이 만족해야 SSM이 SSM agent가 설치된 노드를 관리할 수 있습니다.
- SSM과 SSM agent 네트워크 통신이 가능해야 합니다. default로 public통신을 합니다.
- EC2 Instance profile의 IAM policy에 AmazonSSMManagedInstanceCore가 있어야 합니다. AmazonSSMManagedInstanceCore은 AWS가 관리하는 IAM policy이고 SSM, ssmmessages 등의 policy가 설정되어 있습니다.
설치 확인
AWS에서 관리하는 AMI를 사용하면 SSM Agent는 이미 설치되어 있습니다. systemctl로 SSM agent 상태를 확인할 수 있습니다.
sudo systemctl status amazon-ssm-agent
sudo tail -f /var/log/amazon/ssm/amazon-ssm-agent.log
운영체제마다 ssm agent이름은 달라질 수 있습니다. 예를 들면 ubuntu linux는 snap.amazon-ssm-agent입니다. SSM agent이름은 systemd 목록을 조회하면 얻을 수 있습니다.
systemctl status amazon-ssm-agent.amazon-ssm-agent
SSM agent로그는 /var/log/amazon/ssm위치에 저장됩니다.
sudo tail -f /var/log/amazon/ssm/amazon-ssm-agent.log
Fleet Manager: 노드 등록과 관리
Fleet Manager는 집합(fleet)이라는 단어 뜻대로, SSM에 등록된 노드를 집합형태로 관리합니다.
관리의 기능은 Systems Manager에 등록된 노드 상태가 정상인지 실패인지 상태를 확인합니다. 또한 파일 이름 변경, 생성 등 파일 관리 기능, 프로세스 조회, CPU사용량 확인 등을 할 수 있습니다.
Fleet Manager에 노드를 등록하는 방법은 SSM agent가 정상적으로 실행되면 됩니다. 실행조건 2가지(EC2 IAM profile의 policy, network)입니다.
Session Manager
Session Manager는 노드에 세션을 생성하여 사용자가 실시간으로 명령어를 실행하고, 명령어 실행결과를 볼 수 있습니다. 마치 원격접속처럼 동작합니다. Session Manager 세션은 start-session API로 생성됩니다. 현재 세션은 SSM console에서 확인할 수 있습니다.
제가 원격접속이 아니라고 생각한 이유는 클라이언트가 직접 노드에 붙지 않는다고 생각하기 때문입니다. 사용자는 SSM Session Manager와 websocket 세션을 맺고, System Session Manager가 EC2인스턴스와 TLS 세션을 맺는다고 생각합니다.
노드에서 직접 디버깅하면 ssm-agent-worker 프로세스 하위에 443/TLS 세션이 생긴것을 알 수 있습니다.
pstree
ss -tunap | grep ssm
세션은 EC2 instance에서 Connect → Session Manager를 선택하시거나
start-session API를 호출해도 됩니다. start-session API를 호출하려면 Session Manager plugin을 설치해야 합니다.
Run Command
Run Command는 사용자가 요청한 명령어를 노드에 실행합니다. Run command가 실행할 명령어는 SSM document에서 관리하고 노드에서 실행한 명령어는 S3, cloudatch logs에 저장할 수 있습니다.
Run Command를 생성할 때 실행할 명령어를 관리하는 SSM Document를 지정합니다.
그리고 명령어를 실행할 노드를 설정하는데 EC2인스턴스 tag, 인스턴스 id 등으로 필터링할 수 있습니다.
Distributor
SSM Distributor는 패키지를 노드에 설치하는 서비스입니다. 설치할 패키지 파일과 스크립트는 s3에 저장합니다. Distributor를 생성하면 아래처럼 SSM document처럼 작업 명세서가 생성됩니다.
Distributor을 실행하려면 install on a schdule 또는 install one time 버튼을 클릭해야 합니다. schdule 또는 one time은 SSM state manager가 생성됩니다. state manager와 Distributor가 연결된 상태를 Associate되었다고 합니다.
State Manager는 Distributor를 SSM Doucment로 취급합니다. Associate된 state manager를 보면 Document name이 보이고 AWS-ConfigureAWSPackage로 설정되어 있습니다.
state manager는 실행옵션과 실행후 작업이 많습니다. 또한, 명령어를 실행하는 노드 수도 조절이 가능합니다.
Distributor가 설치하는 패키지는 S3에 저장해야 합니다. 패키지 구조는 manifests.json과 패키지와 설치 스크립트가 포함된 압축파일입니다. manifests.json은 설치 패키지의 정보입니다.
- 정보 버전
- 어떤 OS에서 패키지 설치가 지원하는지 그리고 패키지 압축파일 경로
- 패키지 압축 파일 hash
압축파일에는 설치 스크립트(install.sh), 삭제 스크립트(uninstall.sh) 그리고 옵션으로 바이너리 파일로 구성됩니다.
재밌는 부분은 노드는 S3에 접근하지 않습니다. SSM이 S3에 있는 패키지를 다운로드 받은 후 internal SSM storage에 압축을 해제합니다. 그리고 노드가 internal SSM storage에 있는 패키지를 가져오고 패키지를 설치합니다. 그러므로, EC2 instance profile에는 S3접근 권한이 없어도 됩니다.
SSM internal storage에 대한 설명은 아래 링크에서 확인할 수 있습니다.
Run command vs Distributor
Run command로도 노드에 패키지를 설치할 수 있습니다. 그러면 run command와 Distributor의 차이는 뭘까요? 패키지 설치에 집중하고 싶다면 Distributor가 Run command보다 좋은 옵션이 많습니다.
Run command는 명령어를 한번만 실행하는 일회성입니다. 또한, OS종류, OS버전별로 패키지를 설치하는 것을 다루려면 Run command가 실행하는 명령어가 복잡해집니다. 반대로 Distributor은 명령어를 cron 규칙으로 스케쥬링할 수 있고 OS종류, 버전별로 설치 명령어를 분리해서 관리할 수 있습니다. cron 규칙이외에 명령어 실행 비율, 알람, 캘린더 연동 등을 설정할 수 있습니다.
EKS 관점에서 AWS SSM을 사용해야할까?
EKS관점에서 모든 노드에 설치해야하는 것은 daemonset로 실행할 수 있습니다. daemonset으로 실행하면 좋은 점은 kubernetes native하기 때문에 kubernets 라이플사이클을 준수합니다.
하지만, 단점은 pod가 커널에 접근해야하는 경우 pod에 높은 권한을 부여해야합니다. 또한, pod가 생성하기 위해 IP를 사용하기 때문에 IP가 부족한 클러스터에서는 부담입니다.
따라서 pod가 높은 권한을 가져서 사내 보안정책에 위반되거나 subnet IP가 부족하다면 SSM으로 관리하는 것을 생각할 수 있습니다. 또는 golden AMI를 만들어서 노드를 교체하는 방법도 있습니다.
참고자료
- https://aws.amazon.com/ko/systems-manager/
- https://aws.amazon.com/ko/blogs/korea/new-aws-systems-manager-fleet-manager/
- https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html
- private SSM: https://devopscube.com/aws-ssm/
- https://medium.com/data-science/aws-system-manager-manage-server-remotely-4f8ffe63575d
- endpoint: https://aws.amazon.com/ko/blogs/mt/automated-configuration-of-session-manager-without-an-internet-gateway/
- https://aws.amazon.com/ko/blogs/opensource/managing-aws-distro-for-opentelemetry-collector-with-aws-systems-manager-distributor/
- Distributor: https://docs.aws.amazon.com/systems-manager/latest/userguide/distributor-getting-started.html
'전공영역 공부 기록' 카테고리의 다른 글
| Kubeflow pipeline (2) | 2025.09.01 |
|---|---|
| kubeflow volume이란? (1) | 2025.08.31 |
| kubeflow - notebook이란? (1) | 2025.08.31 |
| 오류있는 pod를 10시간 디버깅해보니, 원인은 ARM64 미호환 (0) | 2025.08.22 |
| kubeflow model registry ui는 ARM을 지원하지 않는다. (0) | 2025.08.18 |