[네트워크] Systems Manager 이해하기

들어가며

아키텍처를 설계하면서, 견고한 아키텍처를 설계하려면 어떻게 해야 할까 늘 고민하고 있습니다. 아키텍처의 네트워크 환경을 잘 구축하려면 어떻게 해야 할까 고민하던 중, VPC 개념에 대해 알 수 있었습니다. VPC에서 private subnet에 위치한 DB를 SSM을 활용하며 접근하기 위해 인프라 환경을 설정했는데요. SSM이란 무엇이며, 어떻게 SSM을 활용할 수 있는지에 대해 정리해야겠다고 생각했습니다. 그럼 지금부터 SSM에 대해 알아보겠습니다.

 

 

 

 

 

---

 

 

 

 

 

 

 

SSM

EC2에 SSH로 접근하려면, 키 페어를 활용해서 접근할 수 있는데요. 만약 SSH에 접근해야 하는 EC2가 늘어날수록, 관리해야 하는 키 페어가 많아질 수도 있습니다. 만약 하나의 키페어를 활용해서 접근한다 하더라도, 다른 개발자가 EC2에 접근하려 할 때, 키 페어를 공유해줘야 합니다. 만약 개발자가 늘어난다면, 키페어를 많은 개발자들에게 공유해야 하기 때문에, 유출의 가능성이 생길 수 있습니다. 만약 키 페어가 유출되거나 문제가 생기면, 키 페어를 교체해줘야 하는 번거로움도 생깁니다. 

 

이런 불편함을 해소시켜 주는 것이 바로 AWS Systems Manager입니다. 이는 완전 관리형 AWS 서비스로 EC2 및 온프레미스 인스턴스, 가상머신을 브라우저 기반의 쉘 혹은 AWS CLI로 관리할 수 있는 서비스입니다. 

 

만약 Private Subnet에 존재하는 EC2에 접근하려면, Bastion Host를 거쳐서 접근해야 하는데요. Bastion Host 없이, Private Subnet에 위치한 EC2 인스턴스에 접근하려면 어떻게 할 수 있을까요? 이때 사용할 수 있는 것이 바로 AWS Systems Manager의 기능 중 Session Manager라는 기능입니다. 이에 대해 알아보겠습니다. 

 

 

 

Session Manager

Session Manager란 AWS Systems Manager(SSM)의 기능으로, 포트가 아닌 IAM 권한을 갖고 통신하는 시스템입니다. 인스턴스에 대해 원클릭 액세스를 제공하는 관리형 서비스입니다. 인스턴스에 SSH 연결하지 않고 포트를 열 필요 않고, Bastion Host를 유지할 필요 없이 인스턴스에 로그인이 가능합니다.

 

만약 수백 개의 인스턴스를 관리해야 한다면, 일일이 로그인을 위한 키 파일을 관리하지 않아도 됩니다. 또한 개발자 별로 지정된 팀의 인스턴스만 로그인할 수 있도록 구성할 수 있습니다. 또한 웹브라우저 기반으로 OS와 무관하게 사용가능하다는 점도 큰 장점이며, 로깅과 감사도 가능합니다. 언제 어디서 누가 접속했는지 CloudTrail을 활용하여 확인할 수 있고, S3 혹은 CloudWatch를 활용하여 접속 기록과 사용한 모든 커맨드 및 출력 내역을 전송할 수 있습니다.  

 

그럼 이제 Private Subnet에 있는 인스턴스에 접근하는 방법에 대해 알아보겠습니다. 이를 위해 먼저 준비되어야 할 것들이 있는데요.

 

 

먼저 IAM Role이 필요합니다. 생성을 위해 IAM에 들어가 역할 생성 버튼을 클릭합니다.

 

 

 

 

그 후 EC2RoleforSSM을 입력하여, 나오는 정책을 선택하고 다음 버튼을 눌러 역할을 생성합니다. 

 

 

만약 Amazon Linux로 EC2를 생성했다면, EC2 Instance에 SSM Agent가 기본적으로 되어 있을 것이지만, 만약 AWS mamaged AMI가 아닌 경우 SSM Agnet가 설치되어 있지 않기 때문에, 별도로 SSM Agent를 설치해야 합니다. 설치 방법은 아래 링크에서 확인하실 수 있습니다. 

 

 

 

Amazon Linux 인스턴스에 SSM Agent 수동 설치 - AWS Systems Manager

SSM Agent용 EC2 인스턴스에 수동으로 Windows Server 설치 - AWS Systems Manager

SSM Agent용 EC2 인스턴스에 수동으로 macOS 설치 - AWS Systems Manager

 

 

그 후, 만약 Private Subnet에 존재하는 EC2를 생성했다면, EC2RoleforSSM 권한을 생성한 IAM 역할을 EC2에 연결해줘야 합니다. 이를 위해 IAM 역할을 연결할 EC2를 선택하여 작업 > 보안 > IAM 역할 수정 버튼을 클릭합니다. 

 

 

 

 

 

저는 MySSMRoleForEc2라는 역할 이름을 만들어서, Private Subnet에 위치한 EC2의 IAM 역할로 설정했습니다. 그 후 VPC Endpoint에 들어가서, interface endpoint를 3개 생성합니다.

 

 

 

 

 

3개를 만들었다면 그 후에는 Systems Manager의 Session Manager로 들어가서, CloudWatch Logging을 활성화할 것입니다. 이를 위해 먼저 CloudWatch의 로그 그룹을 생성합니다. 

 

 

로그 그룹 생성에서, /test/ssm이라는 이름으로 로그 그룹을 생성하겠습니다. 그 후 다시 Session Manager로 가서 CloudWatch Logging 활성화 부분으로 다시 돌아갑니다. 

 

 

 

여기서 CloudWatch logging을 Enable 설정하고, Enforce encryption에 대해 선택을 해제합니다. 그 후 CloudWatch 로그 그룹에 방그 생성한 로그 그룹을 선택합니다. 여기까지 하고 세션 매니저로 EC2에 접속을 하려 하면, 접근이 안될 것입니다. 왜냐하면 

 

CloudWatch logging을 Enabled 시켰는데, 로그에 저장하기 위한 VPC 엔드포인트를 추가하지 않았기 때문입니다. 이 문제 해결을 위해 VPC 엔드포인트를 하나 더 추가합니다. 

 

 

 

 

 

logs라는 이름의 엔트포인트를 추가로 생성했고, 그다음 세션 시작을 누르면 연결이 될 것입니다. 이를 통해 세션 매니저를 활용해서 Private Subnet의 EC2에 연결하는 방법에 대해 알아봤습니다. 이를 조금 더 잘 활용한다면, Private Subnet에 있는 EC2를 연결해서 Private Subnet에 있는 RDS에 우회해서 접근하는 전략도 구성할 수 있습니다. 

 

 

만약 EC2와 RDS가 Private Subnet에 위치해 있다고 가정하겠습니다. 

 

 

aws ssm start-session --target i-여러분들의 ec2 인스턴스 id --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"portNumber":["rds 포트"],"localPortNumber":["여러분들의 local 환경 port"],"host":["rds 주소"]}'

 

 

 

위와 같이 구성한다면, EC2 인스턴스 localhost:rds port를 내 컴퓨터의 localhost: port로 바인딩할 수 있습니다. 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

마치며

네트워크에 대해 조금씩이라도 지식을 쌓아가고 싶습니다. 기본을 꾸준히 쌓을 수 있는 개발자가 되겠습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

출처

AWS Session Manager로 Private RDS, ElastiCache 접근

gossm 을 사용하여 Private RDS 인스턴스에 접근하기

AWS SSM로 VPN없이 Private 자원 접근하기 - Beomi's Tech blog

[SSM] Bastion 서버를 이용하여 Private 자원 접근하기

[AWS] Session manager를 통하여 RDS 서비스로 터널링

[AWS] AWS SSM(Session Manager) SSH 터널링

Access AWS RDS DB in a Private Subnet (Local/Laptop)

AWS Solution 1 - Session Manager (Public 접근)

AWS Solution 2 - Session Manager (Private 접근)