[AWS] EC2 인스턴스 프로파일 자동 부여 아키텍처 구현

rex.chun
4 min readSep 3, 2022

--

구현 결과물 링크 를 클론하여 글과 같이 살펴보자.

개요

특정 리전에 람다를 생성하고, 이벤트브릿지를 이용해 주기적으로 람다를 트리거하여 EC2의 상태를 점검하고 인스턴스 프로파일이 없거나, 특정 정책이 없는 경우 자동으로 부여하는 아키텍처임

동작설명

인스턴스 프로파일로 사용할 역할 생성

SSM을 사용하기 위한 정책을 보유하고 있는 역할을 인스턴스 프로파일로 사용 가능한 관리형 역할로 생성

2. 이벤트브릿지 및 람다 생성

생성 시 최초 동작 이후 1시간 마다 람다를 트리거하도록 생성

Github에 공개된 람다 모듈을 활용하여 사용하려는 람다 배포

3. 람다 소스코드 살펴보기

코드를 반복적으로 활용하기 위해 ec2.py 라는 모듈과 lambda_function.py 라는 메인 파일로 구성됨

get_available_regions 함수는 실제로 사용 가능한 모든 리전 정보를 받아옴.

get_available_instances 함수는 running 또는 stopped 상태인 인스턴스들의 목록만을 리스트로 변환하여 반환함.

인스턴스 프로파일은 running 또는 stopped 상태일때만 부여 가능

다소 불필요한 부분은 삭제했으며, 예외처리가 없는 상태이기에 실제 프로덕션에서 사용하려고 할 때는 이에 대한 고려가 필요함.

  1. 사용가능한 모든 리전 정보를 획득 후, 리전별 ec2 클라이언트 획득하여 해당 리전의 인스턴스 프로파일 부여 가능한 인스턴스 목록 획득

2. 인스턴스 프로파일 존재 여부를 확인하고, 없을 시 생성한 역할을 부여

associate_iam_instance_profile 함수의 반환값은 성공 후에 기본적으로 associating 을 반환하기 때문에, 정상적인 경우 성공이라 가정하고 내용을 출력함(여기서도 마찬가지로 예외처리 필요)

3. 인스턴프 프로파일이 있는 경우 정책이 잘 들어가있는지 확인 및 부여

인스턴스에서 인스턴스 프로파일 이름을 가져온 후, 해당 인스턴스 프로파일이 붙어 있는 역할명을 가져옴.(여기서는 최초에 나오는 역할에 대해서만 가져오고 있으나, (거의 없겠지만) 혹시나 하나의 인스턴스 프로파일을 여러 역할에 붙인다면 수정이 필요함. => 사실 되는지는 모르겠으나, 리스트 형태로 주길래 되는 느낌이긴 함.)

이후, list_attached_role_policies 함수를 통해 “관리형 정책" 목록을 가져와서 필수로 부여되어 있어야 하는 정책을 검사하고, 없을 경우 attach_role_policy 함수를 통해 정책을 부여함.

4. 인스턴스 프로파일 부여 확인 및 결과 출력

이 부분도 실제 프로덕션에선 조금 더 고민이 필요한 부분임. describe_iam_instance_profile_associations 함수를 통해 associating 상태를 식별하고 존재하는 경우 0.5초를 기다렸다가 다시 수행함.

이후, association_ids 리스트에 값이 존재하는 경우 첫번째 출력을, 아닌 경우 두 번째를 출력함.

여기서도 association_ids의 존재만으로 위의 문구를 출력하려면 반복문 쪽에 예외처리가 필요하며, 더욱 정확한 문구를 사용하려면 실제 부여됐는지 안됐는지 실패한건 아닌지 등이 확인이 필요하긴함.

적용 전 고려할 점

  1. IaC 를 활용하는 경우 해당 아키텍처로 인해 상태가 깨질 수 있음. 이때는 탐지 & 알람 형태로 선회하는 것을 고려해야함.
  2. 일괄로 동일한 역할을 부여하기 때문에 자칫 특정 인스턴스에서 추가 권한이 필요해지면, 기본 인스턴스 프로파일을 보유한 모든 인스턴스가 영향을 받을 수 있음. 이를 해결하기 위해 다른 권한 부여가 필요한 경우 인프라팀에 별도로 인스턴스 프로파일을 부여해달라고 요청해야함.(또는 보안담당자가 직접)
  3. 만약 SCP에서 리전 제어를 하고 있다면 해당 리전에 대한 검사는 제외하는걸 검토해야함.
  4. 특정 계정에서 RunInstances 를 아예 실행하지 못하도록 SCP에서 막았다면 해당 계정에는 관련 역할들을 배포할 필요가 없고, AssumeRole 을 사용하여 다른 계정에 대한 검사를 추가할 때도 포함할 필요가 없다.

이때 조직의 관리계정은 SCP의 영향을 받지 않으므로 제외시키지 않는다.

--

--