SSM Agent에 대한 기술 세부 정보를 알아보기

이 주제의 정보를 사용하여 AWS Systems Manager Agent(SSM Agent)를 구현하고 에이전트의 작동 방식을 이해합니다.

SSM Agent 버전 3.2.x.x 보안 인증 정보 동작

SSM Agent에서는 Quick Setup에서 기본 호스트 관리 구성을 사용하여 인스턴스를 온보딩할 때 /var/lib/amazon/ssm/credentials(Linux 및 macOS의 경우) 또는 %PROGRAMFILES%\Amazon\SSM\credentials(Windows Server의 경우)에서 임시 보안 인증 정보 세트를 저장합니다. 임시 보안 인증 정보에는 기본 호스트 관리 구성을 위해 선택한 IAM 역할에 대해 지정하는 권한이 있습니다. Linux에서는 루트 계정에서만 이러한 보안 인증 정보에 액세스할 수 있습니다. Windows Server에서는 SYSTEM 계정과 로컬 관리자만 이러한 보안 인증 정보에 액세스할 수 있습니다.

SSM Agent 자격 증명 우선순위

다음 주제에서는 SSM Agent가 리소스에서 작업을 수행하기 위해 권한을 부여하는 방법에 대한 중요한 정보를 설명합니다.

SSM Agent가 시스템에 설치되면 Systems Manager 서비스와 통신하기 위해 권한이 필요합니다. Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 이러한 권한은 인스턴스에 연결된 인스턴스 프로파일에 제공됩니다. 비 EC2 시스템의 SSM Agent에서는 일반적으로 /root/.aws/credentials(Linux 및 macOS) 또는 %USERPROFILE%\.aws\credentials(Windows Server)에 있는 공유 보안 인증 정보 파일에서 필요한 권한을 가져옵니다. 필요한 권한은 하이브리드 정품 인증 프로세스 동안에 이 파일에 추가됩니다.

그러나 드물지만 SSM Agent에서 해당 작업을 실행할 수 있는 권한을 확인하는 2개 이상의 위치에 권한이 시스템에 추가될 수 있습니다.

예를 들면, Systems Manager에서 관리하도록 EC2 인스턴스를 구성할 수 있습니다. 해당 구성에는 인스턴스 프로파일 연결이 포함됩니다. 그러나 개발자 또는 최종 사용자 작업에도 해당 인스턴스를 사용하기로 결정하고 여기에 AWS Command Line Interface(AWS CLI)를 설치합니다. 이렇게 설치하면 인스턴스의 자격 증명 파일에 권한이 더 추가됩니다.

인스턴스에서 Systems Manager 명령을 실행할 때 SSM Agent는 인스턴스 프로파일 대신 자격 증명 파일에서와 같이 예상과 다른 자격 증명을 사용하려고 할 수 있습니다. 이는 SSM Agent가 기본 자격 증명 공급자 체인에 대해 규정된 순서대로 자격 증명을 찾기 때문입니다.

기본 공급자 체인은 다음 순서대로 자격 증명을 찾습니다.

관련 내용은 다음 주제를 참조하세요.

FIPS(Federal Information Processing Standard)에 따라 사용하기 위해 SSM Agent 구성

FIPS(Federal Information Processing Standard) 140-3 검증 암호화 모듈과 함께 Systems Manager를 사용해야 하는 경우 지원되는 리전에서 FIPS 엔드포인트를 사용하도록 AWS Systems Manager Agent(SSM Agent)를 구성할 수 있습니다.

구성을 변경할 때마다 SSM Agent를 다시 시작합니다.

동일한 절차를 사용하여 SSM Agent의 다른 기능을 사용자 정의할 수 있습니다. 사용 가능한 구성 속성 및 해당 속성 기본값의 최신 목록은 GitHub의 amazon-ssm-agent 리포지토리에서 Config Property Definitions를 참조하세요.

FIPS에 대한 AWS 지원의 자세한 설명은 FIPS(Federal Information Processing Standard) 140-3을 참조하세요.

로컬 ssm-user 계정 정보

SSM Agent 버전 2.3.50.0부터 에이전트는 ssm-user라는 로컬 사용자 계정을 생성하여 /etc/sudoers.d 디렉터리(Linux 및 macOS)나 Administrators group (Windows Server)에 추가합니다. 2.3.612.0 이전 버전의 에이전트에서 SSM Agent 최초 시작 또는 설치 후 재시작 시 계정이 생성됩니다. 2.3.612.0 이후 버전에서 ssm-user 계정은 인스턴스에서 세션을 처음 시작할 때 생성됩니다. 이 ssm-user는 AWS Systems Manager의 기능인 Session Manager에서 세션이 시작될 때 기본 OS 사용자입니다. ssm-user를 권한이 낮은 그룹으로 이동하거나 sudoers 파일을 변경하여 권한을 변경할 수 있습니다. SSM Agent를 설치 제거해도 ssm-user 계정은 시스템에서 제거되지 않습니다.

Windows Server에서 SSM Agent는 각 세션이 시작될 때 ssm-user 계정에 대한 새 암호 설정을 처리합니다. Linux 관리형 인스턴스의 ssm-user에 대해서는 암호가 설정되지 않습니다.

SSM Agent 버전 2.3.612.0부터 ssm-user 계정은 도메인 컨트롤러로 사용되는 Windows Server 시스템에서 자동으로 생성되지 않습니다. Windows Server 도메인 컨트롤러에서 Session Manager를 사용하려면 ssm-user 계정이 없는 경우 수동으로 생성하고 사용자에게 도메인 관리자 권한을 할당합니다.

SSM Agent 및 Instance Metadata Service(IMDS)

Systems Manager는 올바르게 작동하기 위해 EC2 인스턴스 메타데이터를 사용합니다. Systems Manager는 Instance Metadata Service의 버전 1 또는 버전 2(IMDSv1 및 IMDSv2)를 사용하여 인스턴스 메타데이터에 액세스할 수 있습니다. 인스턴스에서 인스턴스 메타데이터 서비스의 IPv4 주소 169.254.169.254에 액세스할 수 있어야 합니다. 자세한 내용은 Amazon EC2 사용 설명서의 인스턴스 메타데이터 및 사용자 데이터를 참조하세요.

SSM Agent 최신 상태 유지

SSM Agent의 업데이트된 버전은 Systems Manager에 새 기능이 추가되거나 기존 기능이 업데이트될 때마다 릴리스됩니다. 최신 버전의 에이전트를 사용하지 못하면 관리형 노드에서 다양한 Systems Manager 기능을 사용하지 못할 수 있습니다. 이러한 이유로 시스템의 SSM Agent 상태를 최신 상태로 유지하는 프로세스를 자동화하는 것이 좋습니다. 자세한 내용은 SSM Agent 업데이트 자동화을 참조하세요. SSM Agent 업데이트에 대해 알림을 수신하려면 GitHub에서 SSM Agent 릴리스 정보 페이지를 구독합니다.

SSM Agent 설치 디렉터리가 수정, 이동 또는 삭제되지 않았는지 확인

SSM Agent는 /var/lib/amazon/ssm/(Linux와 macOS) 및 %PROGRAMFILES%\Amazon\SSM\(Windows Server)에 설치됩니다. 이러한 설치 디렉터리에는 보안 인증 파일, IPC(프로세스 간 통신)용 리소스, 오케스트레이션 폴더 등 SSM Agent에서 사용하는 중요한 파일 및 폴더가 포함되어 있습니다. 설치 디렉터리 내의 어떤 내용도 수정, 이동 또는 삭제해서는 안 됩니다. 그렇지 않으면 SSM Agent가 제대로 작동하지 않을 수 있습니다.

AWS 리전의 SSM Agent 롤링 업데이트

GitHub 리포지토리에서 SSM Agent 업데이트를 사용할 수 있게 된 후 업데이트된 버전이 다른 시간에 모든 AWS 리전에 배포될 때까지 최대 2주가 소요될 수 있습니다. 이러한 이유로 리전에서 새 버전의 SSM Agent를 배포하려고 하면 "현재 플랫폼에서 지원되지 않음(Unsupported on current platform)" 또는 "amazon-ssm-agent를 이전 버전으로 업데이트 중, 진행하려면 다운그레이드 허용 설정(updating amazon-ssm-agent to an older version, please turn on allow downgrade to proceed)"과 같은 오류가 표시될 수 있습니다.

사용 가능한 SSM Agent 버전을 확인하려면 curl 명령을 실행합니다.

글로벌 다운로드 버킷에서 사용 가능한 에이전트 버전을 보려면 다음 명령을 실행합니다.

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

특정 리전에서 사용 가능한 에이전트 버전을 보려면 리전을 작업 중인 리전(예: 미국 동부(오하이오) 리전의 경우 us-east-2)으로 바꿔서 다음 명령을 실행합니다.

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

curl 명령 없이 브라우저에서 직접 VERSION 파일을 열 수도 있습니다.

AWS 관리형 S3 버킷과 SSM Agent 통신

다양한 Systems Manager 작업을 수행하는 과정에서 AWS Systems Manager Agent(SSM Agent)는 여러 Amazon Simple Storage Service(Amazon S3) 버킷에 액세스합니다. 이러한 S3 버킷은 공개적으로 액세스할 수 있으며 기본적으로 SSM Agent는 HTTP 호출을 사용하여 연결합니다.

그러나 Systems Manager 작업에서 Virtual Private Cloud(VPC) 엔드포인트를 사용하는 경우 Systems Manager를 위한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 프로파일 또는 하이브리드 및 멀티클라우드 환경의 비 EC2 시스템을 위한 서비스 역할에 명시적 권한을 제공해야 합니다. 그렇지 않을 경우, 리소스가 이러한 퍼블릭 버킷에 액세스할 수 없습니다.

VPC 엔드포인트를 사용할 때 관리형 노드에 이러한 버킷에 대한 액세스 권한을 부여하려면 사용자 정의 Amazon S3 권한 정책을 생성한 다음에 인스턴스 프로파일(EC2 인스턴스의 경우) 또는 서비스 역할(비 EC2 관리형 노드의 경우)에 이를 연결합니다.

Systems Manager 작업에서 Virtual Private Cloud(VPC) 엔드포인트를 사용하는 방법에 대한 자세한 내용은 Systems Manager용 VPC 엔드포인트를 사용하여 EC2 인스턴스의 보안 개선을 참조하세요.

자세한 정보는 다음 주제를 참조하세요.

필요한 버킷 권한

다음 표에서는 SSM Agent가 Systems Manager 작업을 위해 액세스해야 할 수 있는 각 S3 버킷에 대해 설명합니다.

SSM Agent에 필요한 Amazon S3 권한

예

다음 예에서는 미국 동부(오하이오) 리전(us-east-2)에서 Systems Manager 작업에 필요한 S3 버킷에 대한 액세스를 제공하는 방법을 보여줍니다. 대부분의 경우 VPC 엔드포인트를 사용할 때만 인스턴스 프로파일 또는 서비스 역할에서 이러한 권한을 명시적으로 제공해야 합니다.

{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
                    "arn:aws:s3:::us-east-2-birdwatcher-prod/*",
                    "arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-patch-manager-us-east-2-552881074/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2-552881074/*"
                ]
            }
        ]
    }

하드웨어 지문을 사용하여 하이브리드 정품 인증 시스템 검증

비 EC2 시스템이 하이브리드 및 멀티클라우드 환경에 있을 때 SSM Agent에서는 여러 시스템 속성(하드웨어 해시라고 함)을 수집하고 이러한 속성을 사용하여 지문을 계산합니다. 지문은 에이전트가 특정 Systems Manager API에 전달하는 불투명 문자열입니다. 이 고유 지문은 호출자를 특정 하이브리드 정품 인증 관리형 노드와 연결합니다. 에이전트는 로컬 디스크의 저장소라는 위치에 지문 및 하드웨어 해시를 저장합니다.

에이전트에서는 Systems Manager에서 사용하도록 시스템이 등록될 때 하드웨어 해시와 지문을 계산합니다. 그런 다음 에이전트가 RegisterManagedInstance 명령을 전송할 때 Systems Manager 서비스로 지문이 다시 전달됩니다.

나중에 RequestManagedInstanceRoleToken 명령을 전송할 때 에이전트는 현재 시스템 속성이 저장된 하드웨어 해시와 일치하는지 확인하기 위해 저장소의 지문 및 하드웨어 해시를 확인합니다. 현재 시스템 속성이 저장소에 저장된 하드웨어 해시와 일치하는 경우 에이전트는 저장소에서 RegisterManagedInstance로 지문을 전달하여 호출에 성공합니다.

현재 시스템 속성이 저장된 하드웨어 해시와 일치하지 않으면 SSM Agent는 새 지문을 계산하고 저장소에 새 하드웨어 해시와 지문을 저장하고 새 지문을 RequestManagedInstanceRoleToken에 전달합니다. 이로 인해 RequestManagedInstanceRoleToken이 실패하고 에이전트는 Systems Manager 서비스에 연결하기 위한 역할 토큰을 얻을 수 없습니다.

이 실패는 의도적으로 설계된 것이며 여러 관리형 노드가 동일한 관리형 노드로 Systems Manager 서비스와 통신하지 못하도록 하기 위한 확인 단계로 사용됩니다.

현재 시스템 속성을 저장소에 저장된 하드웨어 해시와 비교할 때 에이전트는 다음 논리를 사용하여 이전 해시와 새 해시가 일치하는지 확인합니다.

유사성 임계값은 저장소에 하드웨어 해시의 일부로 저장됩니다.

유사성 임계값은 다음과 같은 명령을 사용하여 인스턴스를 등록한 후에 설정할 수 있습니다.

Linux 시스템의 경우:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

PowerShell을 사용하는 Windows Server 시스템의 경우:

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

GitHub​의 SSM Agent

SSM Agent의 소스 코드는 GitHub에 제공되므로 필요에 따라 에이전트를 조정할 수 있습니다. 포함하고 싶은 변경에 대해서는 풀 요청을 제출하는 것이 좋습니다. 단, Amazon Web Services에서 이 소프트웨어의 수정된 사본 실행을 지원하지 않습니다.