전송 계층 보안(TLS) - AWS 앱 메시
인증서 요구 사항TLS 인증 인증서App Mesh가 협상을 위해 Envoys를 구성하는 방법 TLS암호화 확인인증서 갱신에서 TLS 인증을 사용하도록 Amazon ECS 워크로드 구성 AWS App Mesh에서 TLS 인증을 사용하도록 Kubernetes 워크로드 구성 AWS App Mesh

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

전송 계층 보안(TLS)

중요

지원 종료 알림: 2026년 9월 30일에 에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은 이 블로그 게시물에서 에서 Amazon ECS Service Connect AWS App Mesh 로 마이그레이션을 참조하세요.

App Mesh에서 Transport Layer Security(TLS)는 가상 노드 및 와 같은 메시 엔드포인트로 App Mesh에 표시되는 컴퓨팅 리소스에 배포된 Envoy 프록시 간의 통신을 암호화합니다가상 게이트웨이. 프록시는 를 협상하고 종료합니다TLS. 프록시가 애플리케이션과 함께 배포되는 경우 애플리케이션 코드는 TLS 세션 협상에 대한 책임이 없습니다. 프록시는 TLS 애플리케이션을 대신하여 협상합니다.

App Mesh를 사용하면 다음과 같은 방법으로 프록시에 TLS 인증서를 제공할 수 있습니다.

  • AWS Certificate Manager (ACM)에서 발급한 ()의 AWS Private Certificate Authority 프라이빗 인증서입니다AWS Private CA.

  • 자체 인증 기관(CA)에서 발급한 가상 노드의 로컬 파일 시스템에 저장된 인증서

  • 로컬 Unix 도메인 소켓을 통해 Secrets Discovery Service(SDS) 엔드포인트에서 제공하는 인증서입니다.

메시 엔드포인트로 표시되는 배포된 Envoy 프록시에 대해 Envoy 프록시 권한 부여를 활성화해야 합니다. 프록시 권한 부여를 활성화할 때는 암호화를 활성화하려는 메시 엔드포인트로만 액세스를 제한합니다.

인증서 요구 사항

인증서의 주체 대체 이름(SANs) 중 하나는 메시 엔드포인트로 표시되는 실제 서비스가 검색되는 방식에 따라 특정 기준과 일치해야 합니다.

  • DNS – 인증서 중 하나가 DNS 서비스 검색 설정에 제공된 값과 일치해야 SANs 합니다. 서비스 검색 이름이 mesh-endpoint.apps.local인 애플리케이션의 경우 해당 이름과 일치하는 인증서 또는 와일드카드 *.apps.local을 포함하는 인증서를 생성할 수 있습니다.

  • AWS Cloud Map – 인증서 중 하나는 형식을 사용하여 AWS Cloud Map 서비스 검색 설정에 제공된 값과 일치해야 SANs 합니다service-name.namespace-name. serviceName mesh-endpoint 및 의 AWS Cloud Map 서비스 검색 설정이 있는 애플리케이션의 경우 이름과 일치하는 인증서 mesh-endpoint.apps.local또는 와일드 카드가 있는 인증서를 생성할 namespaceName apps.local수 있습니다. *.apps.local.

두 검색 메커니즘 모두에서 DNS 서비스 검색 설정과 SANs 일치하는 인증서가 없는 경우 클라이언트 Envoy에서 볼 수 있듯이 다음 오류 메시지와 함께 Envoys 간의 연결이 실패합니다.

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLS 인증 인증서

App Mesh는 TLS 인증을 사용할 때 인증서에 대해 여러 소스를 지원합니다.

AWS Private CA

인증서는 인증서를 사용할 메시 엔드포인트와 ACM 동일한 리전 및 AWS 계정에 저장해야 합니다. CA의 인증서는 동일한 AWS 계정에 있을 필요는 없지만 메시 엔드포인트와 동일한 리전에 있어야 합니다. 가 없는 경우 AWS Private CA인증서를 먼저 생성해야 인증서를 요청할 수 있습니다. 를 AWS Private CA 사용하여 기존 에서 인증서를 요청하는 방법에 대한 자세한 내용은 프라이빗 인증서 요청을 ACM참조하세요. https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html 인증서는 퍼블릭 인증서일 수 없습니다.

TLS 클라이언트 정책에 CAs 사용하는 프라이빗은 루트 사용자 여야 합니다CAs.

CAs 에서 인증서 및 를 사용하여 가상 노드를 구성하려면 App Mesh AWS Private CA를 호출하는 데 사용하는 보안 주체(예: 사용자 또는 역할)에 다음 IAM 권한이 있어야 합니다.

  • 리스너의 TLS 구성에 추가하는 인증서의 경우 보안 주체에게 acm:DescribeCertificate 권한이 있어야 합니다.

  • TLS 클라이언트 정책에 CAs 구성된 의 경우 보안 주체에게 acm-pca:DescribeCertificateAuthority 권한이 있어야 합니다.

중요

다른 계정CAs과 공유하면 해당 계정에 의도하지 않은 권한이 CA에 부여될 수 있습니다. 리소스 기반 정책을 사용하여 CA에서 인증서를 발급할 필요가 없는 계정의 acm-pca:DescribeCertificateAuthority 및 acm-pca:GetCertificateAuthorityCertificate로만 액세스를 제한하는 것이 좋습니다.

보안 주체에 연결된 기존 IAM 정책에 이러한 권한을 추가하거나 새 보안 주체 및 정책을 생성하고 보안 주체에 정책을 연결할 수 있습니다. 자세한 내용은 IAM 정책 편집, IAM 정책 생성 및 IAM ID 권한 추가를 참조하세요.

참고

삭제하기 AWS Private CA 전까지는 각 의 작업에 대한 월별 요금을 지불합니다. 또한 매월 발급하는 프라이빗 인증서와 내보내는 프라이빗 인증서에 대한 비용도 지불하면 됩니다. 자세한 내용은 AWS Certificate Manager 요금을 참조하세요.

메시 엔드포인트가 나타내는 Envoy 프록시에 대한 프록시 인증을 활성화하면 사용하는 IAM 역할에 다음 IAM 권한이 할당되어야 합니다.

  • 가상 노드의 리스너에 구성된 모든 인증서의 경우 역할에 acm:ExportCertificate 권한이 있어야 합니다.

  • TLS 클라이언트 정책에 CAs 구성된 의 경우 역할에 acm-pca:GetCertificateAuthorityCertificate 권한이 있어야 합니다.

파일 시스템

파일 시스템을 사용하여 Envoy에 인증서를 배포할 수 있습니다. 인증서 체인과 해당 프라이빗 키를 파일 경로에서 사용할 수 있도록 설정하여 이 작업을 수행할 수 있습니다. 이렇게 하면 Envoy 사이드카 프록시에서 이러한 리소스에 연결할 수 있습니다.

Envoy의 Secret Discovery Service(SDS)

Envoy는 Secrets Discovery 프로토콜을 통해 특정 엔드포인트에서 TLS 인증서와 같은 보안 암호를 가져옵니다. 이 프로토콜에 대한 자세한 내용은 Envoy SDS 설명서 를 참조하세요.

App Mesh는 가 인증서 및 인증서 체인의 소스 SDS 역할을 할 때 보안 검색 서비스(SDS) 엔드포인트 역할을 하도록 프록시에 로컬인 Unix 도메인 소켓을 사용하도록 Envoy 프록시를 구성합니다. APPMESH_SDS_SOCKET_PATH 환경 변수를 사용하여 이 엔드포인트에 대한 경로를 구성할 수 있습니다.

중요

Unix 도메인 소켓을 사용하는 로컬 보안 암호 검색 서비스는 App Mesh Envoy 프록시 버전 1.15.1.0 이상에서 지원됩니다.

App Mesh는 g를 사용하는 V2 SDS 프로토콜을 지원합니다RPC.

SPIFFE 런타임 환경과 통합(SPIRE)

SPIFFE 런타임 환경(SPIRE)과 같은 기존 도구 체인을 API포함하여 SDS 의 모든 사이드카 구현을 사용할 수 있습니다. SPIRE 는 분산 시스템의 여러 워크로드 간에 상호 TLS 인증을 배포할 수 있도록 설계되었습니다. 런타임 시 워크로드의 자격 증명을 증명합니다. SPIRE 또한 는 워크로드별, 수명이 짧고 자동으로 회전하는 키와 인증서를 워크로드에 직접 제공합니다.

SPIRE 에이전트를 Envoy의 SDS 공급자로 구성해야 합니다. 상호 TLS 인증을 제공하는 데 필요한 키 구성 요소를 Envoy에 직접 공급하도록 허용합니다. Envoy 프록시 옆의 사이드카에서 SPIRE 에이전트를 실행합니다. 이 Agent는 필요에 따라 수명이 짧은 키와 인증서를 다시 생성합니다. 에이전트는 Envoy를 증명하고 Envoy가 SPIRE 에이전트가 노출한 SDS 서버에 연결할 때 Envoy에 제공해야 하는 서비스 ID 및 CA 인증서를 결정합니다.

이 프로세스 중에 서비스 자격 증명과 CA 인증서가 교체되고 업데이트가 Envoy로 다시 스트리밍됩니다. Envoy는 중단이나 가중 중지 없이, 그리고 파일 시스템에 프라이빗 키를 제공할 필요 없이 새 연결에 이러한 항목을 즉시 적용합니다.

App Mesh가 협상을 위해 Envoys를 구성하는 방법 TLS

App Mesh는 메시에서 Envoy 간의 통신을 구성하는 방법을 결정할 때 클라이언트와 서버의 메시 엔드포인트 구성을 사용합니다.

클라이언트 정책 사용

클라이언트 정책이 의 사용을 강제TLS하고 클라이언트 정책의 포트 중 하나가 서버 정책의 포트와 일치하는 경우 클라이언트 정책은 클라이언트의 TLS 검증 컨텍스트를 구성하는 데 사용됩니다. 예를 들어 가상 게이트웨이의 클라이언트 정책이 가상 노드의 서버 정책과 일치하는 경우 가상 게이트웨이의 클라이언트 정책에 정의된 설정을 사용하여 프록시 간에 TLS 협상이 시도됩니다. 클라이언트 정책이 서버 정책의 포트와 일치하지 않는 경우 서버 정책의 TLS 설정에 따라 프록시 TLS 간에 협상할 수도 있고 협상하지 않을 수도 있습니다.

클라이언트 정책을 사용하지 않는 경우

클라이언트가 클라이언트 정책을 구성하지 않았거나 클라이언트 정책이 서버의 포트와 일치하지 않는 경우 App Mesh는 서버를 사용하여 클라이언트TLS와 협상할지 여부와 방법을 결정합니다. 예를 들어 가상 게이트웨이가 클라이언트 정책을 지정하지 않았고 가상 노드가 TLS 종료를 구성하지 않은 경우 TLS는 프록시 간에 협상되지 않습니다. 클라이언트가 일치하는 클라이언트 정책을 지정하지 않았고 서버가 TLS 모드 STRICT 또는 로 구성된 경우 PERMISSIVE프록시는 협상하도록 구성됩니다TLS. TLS 종료를 위해 인증서가 제공된 방식에 따라 다음과 같은 추가 동작이 적용됩니다.

  • ACM관리형 TLS 인증서 ACM- 서버가 관리형 인증서를 사용하여 TLS 종료를 구성한 경우 App Mesh는 인증서가 연결된 루트 사용자 CA에 대해 인증서를 협상TLS하고 검증하도록 클라이언트를 자동으로 구성합니다.

  • 파일 기반 TLS 인증서 - 서버가 프록시의 로컬 파일 시스템의 인증서를 사용하여 TLS 종료를 구성한 경우 App Mesh는 를 협상하도록 클라이언트를 자동으로 구성TLS하지만 서버의 인증서는 검증되지 않습니다.

주체 대체 이름

선택적으로 신뢰할 주제 대체 이름(SANs) 목록을 지정할 수 있습니다. SANs 는 FQDN 또는 URI 형식이어야 합니다. 이 제공된 경우 EnvoySANs는 제공된 인증서의 주체 대체 이름이 이 목록의 이름 중 하나와 일치하는지 확인합니다.

종료 메시 엔드포인트SANs에 를 지정하지 않으면 해당 노드의 Envoy 프록시가 피어 클라이언트 인증서SAN에서 를 확인하지 않습니다. 원래 메시 엔드포인트SANs에서 를 지정하지 않으면 종료 엔드포인트에서 제공하는 SAN 인증서의 이 메시 엔드포인트 서비스 검색 구성과 일치해야 합니다.

자세한 내용은 App Mesh TLS: 인증서 요구 사항 섹션을 참조하세요.

중요

SANs 에 대한 클라이언트 정책TLS이 로 설정된 경우에만 와일드카드를 사용할 수 있습니다not enforced. 클라이언트 가상 노드 또는 가상 게이트웨이에 대한 클라이언트 정책이 를 적용하도록 구성된 TLS경우 와일드카드 를 수락할 수 없습니다SAN.

암호화 확인

를 활성화하면 Envoy 프록시를 쿼리하여 통신이 암호화되었는지 확인할 TLS수 있습니다. Envoy 프록시는 TLS 통신이 제대로 작동하는지 이해하는 데 도움이 될 수 있는 리소스에 대한 통계를 내보냅니다. 예를 들어 Envoy 프록시는 지정된 메시 엔드포인트에 대해 협상한 성공적인 TLS 핸드셰이크 수에 대한 통계를 기록합니다. 다음 명령을 my-mesh-endpoint 사용하여 라는 메시 엔드포인트에 대해 몇 개의 성공적인 TLS 핸드셰이크가 있었는지 확인합니다.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep ssl.handshake

다음 예제의 반환된 출력에서는 메시 엔드포인트에 대한 핸드셰이크가 세 번 있었으므로 통신이 암호화됩니다.

listener.0.0.0.0_15000.ssl.handshake: 3

Envoy 프록시는 TLS 협상에 실패할 때도 통계를 내보냅니다. 메시 엔드포인트에 TLS 오류가 있는지 확인합니다.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep -e "ssl.*\(fail\|error\)"

반환된 출력 예제에서는 여러 통계에 오류가 없어 TLS 협상에 성공했습니다.

listener.0.0.0.0_15000.ssl.connection_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_cert_hash: 0
listener.0.0.0.0_15000.ssl.fail_verify_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_no_cert: 0
listener.0.0.0.0_15000.ssl.ssl.fail_verify_san: 0

Envoy TLS 통계에 대한 자세한 내용은 Envoy 리스너 통계를 참조하세요.

인증서 갱신

AWS Private CA

를 사용하여 인증서를 갱신하면 ACM갱신 완료 후 35분 이내에 갱신된 인증서가 연결된 프록시에 자동으로 배포됩니다. 유효 기간이 거의 끝나갈 즈음에 인증서를 자동으로 갱신하려면 관리형 갱신을 사용하는 것이 좋습니다. 자세한 내용은 AWS Certificate Manager 사용 설명서의 ACM의 Amazon 발급 인증서에 대한 Managed Renewal을 참조하세요.

자체 인증서

로컬 파일 시스템의 인증서를 사용하는 경우 Envoy는 인증서가 변경되어도 인증서를 자동으로 다시 로드하지 않습니다. Envoy 프로세스를 다시 시작하거나 재배포하여 새 인증서를 로드할 수 있습니다. 새 인증서를 다른 파일 경로에 배치하고 해당 파일 경로로 가상 노드 또는 게이트웨이 구성을 업데이트할 수도 있습니다.

에서 TLS 인증을 사용하도록 Amazon ECS 워크로드 구성 AWS App Mesh

TLS 인증을 사용하도록 메시를 구성할 수 있습니다. 워크로드에 추가하는 Envoy 프록시 사이드카에서 인증서를 사용할 수 있는지 확인합니다. EBS 또는 EFS 볼륨을 Envoy 사이드카에 연결하거나 AWS Secrets Manager에서 인증서를 저장하고 검색할 수 있습니다.

  • 파일 기반 인증서 배포를 사용하는 경우 Envoy 사이드카에 EBS 또는 EFS 볼륨을 연결합니다. 인증서 및 프라이빗 키의 경로가 에 구성된 경로와 일치하는지 확인합니다 AWS App Mesh.

  • SDS기반 배포를 사용하는 경우 인증서에 액세스할 수 SDS API 있는 Envoy를 구현하는 사이드카를 추가합니다.

참고

SPIRE 는 Amazon 에서 지원되지 않습니다ECS.

에서 TLS 인증을 사용하도록 Kubernetes 워크로드 구성 AWS App Mesh

가상 노드 및 가상 게이트웨이 서비스 백엔드 및 리스너에 대한 TLS 인증을 활성화하도록 Kubernetes용 AWS App Mesh 컨트롤러를 구성할 수 있습니다. 워크로드에 추가하는 Envoy 프록시 사이드카에서 인증서를 사용할 수 있는지 확인합니다. 상호 TLS 인증의 연습 섹션에서 각 배포 유형의 예를 볼 수 있습니다.

  • 파일 기반 인증서 배포를 사용하는 경우 Envoy 사이드카에 EBS 또는 EFS 볼륨을 연결합니다. 인증서 및 프라이빗 키의 경로가 컨트롤러에 구성된 경로와 일치하는지 확인합니다. 또는 파일 시스템에 탑재된 Kubernetes Secret을 사용할 수도 있습니다.

  • SDS기반 배포를 사용하는 경우 Envoy의 SDS 를 구현하는 노드 로컬 SDS 공급자를 설정해야 합니다API. Envoy는 를 통해 에 도달합니다UDS. EKS AppMesh 컨트롤러에서 SDS 기반 mTLS 지원을 활성화하려면 enable-sds 플래그를 로 설정하고 sds-uds-path 플래그를 통해 로컬 SDS 공급자의 컨트롤러 UDS 경로를 true 제공합니다. helm을 사용하는 경우 컨트롤러 설치의 일부로 다음을 설정합니다.

    --set sds.enabled=true
참고

Fargate 모드에서 Amazon Elastic Kubernetes Service(AmazonEKS)를 사용하는 경우 를 사용하여 인증서를 SPIRE 배포할 수 없습니다.