개요

보통 SSM이라고 많이 알려진, 세션을 여는데 사용하는 툴.
EC2를 사용하다 보면 인스턴스 내부로 들어가 조작을 해야 하는 경우가 굉장히 많다.
이때 매번 SSH를 이용하지 않고, 다른 방식으로 연결을 지원하는 것이 바로 세션 매니저이다.
원래 이름이 Simple Systems Manager여서 SSM이었는데, 최근에는 그냥 Systems Manager라고 부른다.

그럼에도 SSM이란 네이밍이 아직도 남아서 사용되고 있으니 SSM이라 알고 있는 게 속이 편하리라.

특징

이 Systems Manager라는 것의 하위 도구가 여러 개가 있는데, 가장 기본이 되는 Session Manager를 주로 설명하겠다.
참고로
세션을 연결하는 것은 그냥 바스티온 인스턴스를 두고 ssh를 하면 되는데 뭐하러 쓰나?
바로 그것 때문에 이것을 쓰는 게 의미가 있다.

• ssh 키 관리 필요 없음
• 바스티온 중간자를 둘 필요 없음
• 포트를 따로 열어줄 필요도 없음

기본적인 이러한 장점 이외에도, ssh 포트포워딩과 다르게 자신 내부에서의 포트포워딩만 제공하는 등의 보안적 이점도 있다.
또한 aws에서 자체적으로 제공하는 기능이다보니 로깅, 이벤트 처리 등의 다양한 모니터링을 지원해주기까지 하니, 웬만해서 안 할 이유가 없다.

비교

다른 방식으로 연결하는 방식들이 뭐가 있는가?
간단하게 비교할 수 있게 정리만 해둔다.

• ssh
  • 대상이 ssh 서버를 가진다면 직접 연결
  • 대상이 퍼블릭 ip가 없다면, 바스티온 서버 이용
    • 로컬, 리모트, 다이나믹
• 웹쉘
  • 대상 서버가 웹쉘 기능을 지원한다면 http위로 쉘을 띄움
• ssh over http
  • http위에 ssh를 띄우는 기술도 있다고 한다.^[1]

대충 봐도 제약이 많거나, 보안이 취약하거나, 복잡하다.
세션 매니저는 이러한 고충을 해결해주는 친구이다.

비용

무료!지만 당연히 관련한 다른 리소스에 대해서는 비용이 발생한다.

조건

일단 system manager enpoint에 대한 443 아웃바운드 트래픽은 허용돼야 한다.^[2]
여기에서 느낌이 오겠지만, 사실 http에서 소켓 통신을 뚫어주는 방식으로 동작하는 게 바로 세션 매니저이다.

여기에 적절한 IAM과, 연결되기 위한 인스턴스에는 ssm agent 툴이 설치돼있어야 한다.

구조 및 동작

이 SSM 매니저가 있는 상태에서, 우리가 연결하고자 하는 ec2에 에이전트를 설치하여 연결하면 사용이 가능하다.

아니면 이렇게 콘솔에서 바로 사용하는 것도 가능하다.

보다시피 연결에 있어 systems manager를 거치는 것이 보인다.
실제 공인 ip가 없는 인스턴스라 하더라도 이렇게 공인 ip를 가지고 있는 매니저를 거침으로서 통신이 가능하게 된다.
(그래서 systems manager의 443 enpoint에 접근이 가능해야 한다는 것)
에이전트가 설치돼있을 때 먼저 systems manager에 해당 인스턴스가 등록되고, 여기에 사용자가 접속을 시도하는 방식이다.
인증된 사용자라면 https 터널링을 통해 접속을 시켜주게 된다.

참고로 에이전트는 aws의 ami에 사전 설치돼있는 경우가 많다.^[3]

관련 문서

참고