전송 계층 보안(TLS)

App Mesh에서 전송 계층 보안(TLS)은 App Mesh에 메시 엔드포인트로 표시되는 컴퓨팅 리소스에 배포된 Envoy 프록시(예: 가상 노드 및 가상 게이트웨이) 간의 통신을 암호화합니다. 프록시는 TLS를 협상하고 종료합니다. 프록시가 애플리케이션과 함께 배포되는 경우 애플리케이션 코드는 TLS 세션 협상을 담당하지 않습니다. 프록시가 애플리케이션을 대신하여 TLS를 협상합니다.

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

• (ACM) 에서 발급한 AWS Certificate Manager (ACM) 의 사설 인증서 AWS Private Certificate Authority (AWS Private CA).

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

• 보안 암호 검색 서비스(SDS) 엔드포인트가 로컬 Unix 도메인 소켓을 통해 제공하는 인증서

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

인증서 요구 사항

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

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

• AWS Cloud Map— 인증서 SAN 중 하나는 형식을 사용하여 AWS Cloud Map 서비스 검색 설정에 제공된 값과 일치해야 합니다. service-name.namespace-name mesh-endpointServiceName 및 apps.local NamespaceName의 AWS Cloud Map 서비스 검색 설정을 사용하는 응용 프로그램의 경우 mesh-endpoint.apps.local 이름과 일치하는 인증서 또는 와일드카드가 있는 인증서를 만들 수 있습니다. *.apps.local.

두 검색 메커니즘 모두에서 DNS 서비스 검색 설정과 일치하는 인증서 SAN이 없으면 Envoy 간 연결이 실패하고 클라이언트 Envoy에 표시된 다음 오류 메시지가 표시됩니다.

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLS 인증 인증서

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

AWS Private CA

인증서를 사용할 메시 엔드포인트와 동일한 리전 및 AWS 계정의 ACM에 인증서를 저장해야 합니다. CA의 인증서가 동일한 AWS 계정에 있을 필요는 없지만 메시 엔드포인트와 동일한 지역에 있어야 합니다. 인증서가 없는 AWS Private CA경우 인증서를 요청하려면 먼저 생성해야 합니다. 기존 ACM을 AWS Private CA 사용하여 인증서를 요청하는 방법에 대한 자세한 내용은 사설 인증서 요청을 참조하십시오. 인증서는 퍼블릭 인증서일 수 없습니다.

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

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

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

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

중요

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

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

참고

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

메시 엔드포인트가 나타내는 Envoy Proxy에 대한 프록시 권한 부여를 활성화하는 경우 사용하는 IAM 역할에 다음 IAM 권한을 할당해야 합니다.

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

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

파일 시스템

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

Envoy의 보안 암호 검색 서비스(SDS)

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

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

중요

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

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

SPIFFE Runtime Environment(SPIRE)과의 통합

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

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

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

App Mesh가 TLS를 협상하도록 Envoy를 구성하는 방법

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

클라이언트 정책 사용

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

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

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

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

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

주체 대체 이름

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

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

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

중요

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

암호화 확인

TLS를 활성화한 후에는 Envoy 프록시를 쿼리하여 통신이 암호화되었는지 확인할 수 있습니다. 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\)"

예제의 반환된 출력에서는 여러 통계에 대해 오류가 0개였으므로 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분 이내에 갱신된 인증서가 연결된 프록시에 자동으로 배포됩니다. 유효 기간이 거의 끝나갈 즈음에 인증서를 자동으로 갱신하려면 관리형 갱신을 사용하는 것이 좋습니다. 자세한 내용은 사용 설명서의 ACM Amazon 발급 인증서에 대한 관리형 갱신을 참조하십시오. AWS Certificate Manager

자체 인증서

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

다음과 같이 TLS 인증을 사용하도록 Amazon ECS 워크로드를 구성합니다. AWS App Mesh

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

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

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

참고

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

다음과 같이 TLS 인증을 사용하도록 Kubernetes 워크로드를 구성합니다. AWS App Mesh

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

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

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

  --set sds.enabled=true

참고

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