AWS Certificate Manager

AWS Certificate Manager (ACM)를 서비스 메시 CA로 사용

이 페이지는 AWS Certificate Manager (ACM) Private Certificate Authority (CA)를 Consul 서비스 메시의 인증 기관으로 사용하는 과정을 설명해요. Consul은 ACM Private CA로 인증서를 관리하고 서명할 수 있어요.

출처: 문서

본문

이 페이지는 AWS Certificate Manager (ACM) Private Certificate Authority (CA)를 Consul 서비스 메시의 인증 기관으로 사용하는 과정을 설명합니다.

소개 (Introduction)

Consul은 AWS Certificate Manager (ACM) Private Certificate Authority (CA)와 함께 사용하여 인증서를 관리하고 서명할 수 있습니다.

이 페이지는 AWS ACM Private CA 공급자의 세부 사항을 문서화합니다. 먼저 certificate management overview 페이지를 읽고 Consul이 구성 가능한 CA 공급자로 인증서를 어떻게 관리하는지 이해하세요.

요구 사항 (Requirements)

ACM Private CA Provider는 Consul 1.7.0에 추가되었습니다.

ACM Private CA Provider는 작업을 수행하기 위해 IAM 자격 증명으로 승인되어야 합니다. 모든 Consul 서버는 적절한 IAM 구성이 있는 환경에서 실행되어야 합니다.

표준 AWS SDK 자격 증명 위치가 사용되며, 이는 다음 중 하나에 적절한 자격 증명과 리전 구성이 있어야 함을 의미합니다.

환경 변수
공유 자격 증명 파일
EC2 인스턴스 역할을 통한 방법

제공된 IAM 자격 증명은 다음 작업에 대한 권한이 있어야 합니다.

CreateCertificateAuthority - existing_arn에 기존 CA가 지정되지 않은 경우 가정
DescribeCertificateAuthority
GetCertificate
IssueCertificate

구성 (Configuration)

ACM Private CA 공급자는 에이전트의 ca_provider 구성 옵션에서 CA 공급자를 "aws-pca"로 설정하거나 /connect/ca/configuration API 엔드포인트로 활성화됩니다. 현재 선택적 구성 값은 하나뿐입니다.

예시 구성은 아래와 같습니다.

서비스 메시 CA 구성

/etc/consul.d/config.hcl

# ...
connect {
    enabled = true
    ca_provider = "aws-pca"
    ca_config {
      existing_arn = "arn:aws:acm-pca:region:account:certificate-authority/12345678-1234-1234-123456789012"
    }
}

참고: 공급자가 작동하려면 적절한 AWS IAM 자격 증명이 필요합니다. 그러나 이는 일반적으로 디스크에 있는 Consul 구성에 구성되지 않고 표준 AWS SDK 구성 위치에 의존합니다.

구성 옵션은 아래에 나열되어 있습니다.

참고: 첫 번째 키는 API 호출에서 사용되는 값이고 두 번째 키(/ 이후)는 에이전트의 구성 파일에 구성을 추가하는 경우 사용됩니다.

ExistingARN / existing_arn (string: <optional>) - ACM 계정의 기존 프라이빗 CA의 Amazon Resource Name(ARN). 지정하면 Consul은 기존 CA를 사용해 인증서를 발급하려고 시도합니다.
- 기본 데이터센터에서 이 ARN은 루트 CA를 식별해야 합니다. limitations을 참조하세요.
- 보조 데이터센터에서는 기본 데이터센터에서 사용된 것과 같은 루트에 서명된 하위(subordinate) CA를 식별해야 합니다. 다른 루트에 의해 서명된 경우 Consul은 대신 기본 루트에 서명된 새 하위를 자동으로 생성합니다.
- ExistingARN을 지정하지 않는 기본 동작은 Consul이 기본 데이터센터에 새 루트 CA를 만들고 각 보조 DC에 하위 CA를 만드는 것입니다.

공통 CA 구성 옵션

다음 구성 옵션은 모든 CA 공급자가 지원합니다.

CSRMaxConcurrent / csr_max_concurrent (int: 0) - 동시에 처리할 수 있는 Certificate Signing Request 수에 제한을 설정합니다. 기본값은 0(비활성화)입니다. 이는 서버가 인증서 서명 작업에 사용할 수 있는 CPU 코어 수를 제한하려 할 때 유용합니다. 예를 들어 8코어 서버에서 이 값을 1로 설정하면 인증서를 생성하거나 교체할 때 하나 이상의 CPU 코어가 소비되지 않도록 보장합니다. 회전을 인위적으로 늦추지 않고 CSR 리소스를 제한하는 것을 추론하기 더 간단하므로 CPU 코어 수를 제한하려면 csr_max_per_second 대신 이 값을 설정하는 것이 좋습니다. 1.4.1에서 추가되었습니다.
CSRMaxPerSecond / csr_max_per_second (float: 50) - 서버가 수락할 Certificate Signing Request(CSR)의 최대 수에 대한 속도 제한을 설정합니다. 이는 CA 교체가 서버에서 무제한 CPU 사용을 일으키는 것을 방지하는 데 사용됩니다. 기본값은 보수적인 50입니다. 2017 MacBook은 하나의 CPU 코어의 약 40%만 사용하여 초당 약 100개를 처리할 수 있습니다. 그러나 ~1500 서비스 인스턴스까지의 배포에는 회전 시간이 영향을 받기 전까지 충분합니다. 더 큰 배포의 경우 예상 서버 인스턴스 수와 서버 리소스를 기반으로 이 값을 높이거나, 서버에 CPU 코어가 두 개 이상인 경우 csr_max_concurrent를 대신 사용하는 것이 좋습니다. 이 값을 0으로 설정하면 속도 제한이 비활성화됩니다. 1.4.1에서 추가되었습니다.
LeafCertTTL / leaf_cert_ttl (duration: "72h") - 서비스에 대해 발급된 리프 인증서의 임대 기간 상한. 대부분의 경우 이 한도에 도달하기 전에 프록시가 새 리프 인증서를 요청합니다. 이는 서버 중단(리더 없음)이 네트워크 연결이 거부되기 시작하기 전까지 지속될 수 있는 유효 제한이기도 합니다. 기본값은 72h입니다. 이 값은 1시간보다 낮거나 1년보다 높을 수 없습니다.
- 이 값은 클러스터에서 이전 루트 인증서를 교체할 때도 사용됩니다. 루트 인증서가 현재 leaf_cert_ttl의 두 배보다 오랫동안 비활성(교체됨) 상태였으면 신뢰 목록에서 제거됩니다.
RootCertTTL / root_cert_ttl (duration: "87600h") - 루트 인증서의 수명(TTL). 기본값은 87600h인 10년입니다. 제공된 경우 이 값은 중간 인증서 TTL보다 높아야 합니다.이 설정은 모든 Consul CA 공급자에 적용됩니다.Vault 공급자의 경우 이 값은 백엔드가 처음에 초기화되지 않은 경우에만 사용됩니다.
IntermediateCertTTL / intermediate_cert_ttl (duration: "8760h") - 기본 데이터센터의 루트 인증서에 의해 서명된 중간 인증서의 수명(TTL). 이 필드는 기본 데이터센터에서만 유효합니다. 기본값은 8760h인 1년입니다.이 설정은 모든 Consul CA 공급자에 적용됩니다.Vault 공급자의 경우 이 값은 백엔드가 처음에 초기화되지 않은 경우에만 사용됩니다.
PrivateKeyType / private_key_type (string: "ec") - 이 CA에 대해 생성할 키 유형. 공급자가 새 키를 생성할 때만 사용됩니다. Consul 공급자에 대해 private_key가 설정되거나 Vault에 기존 루트 또는 중간 PKI 경로가 주어지면 무시됩니다. 현재 지원되는 옵션은 ec 또는 rsa입니다. 기본값은 ec입니다. 데이터센터의 모든 서버가 CA에 대해 동일한 구성을 갖는 것이 필요합니다. 내장 CA와 Vault 공급자는 모두 혼합 CA 키 유형을 허용하지만, 다른 데이터센터의 서버가 같은 키 유형과 크기를 사용하는 것이 좋습니다. 일부 CA 공급자(현재 Vault)는 다른 키 유형으로 새 CA 인증서를 교차 서명하는 것을 허용하지 않습니다. 이는 RSA 키 Vault CA에서 어떤 공급자의 EC 키 CA로 마이그레이션하는 경우 교차 서명 없이 진행해야 할 수 있음을 의미하며, 새 인증서 롤아웃 중 워크로드에 일시적인 연결 문제가 발생할 수 있습니다. 프로덕션 밖에서 이를 테스트하여 영향을 이해하는 것을 매우 권장하며, 가능하면 동일한 키 유형을 고수할 것을 제안합니다.참고: 이는 공급자가 생성한 CA 키에만 영향을 줍니다. 리프 인증서 키는 CA 구성과 무관하게 항상 EC 256입니다.
PrivateKeyBits / private_key_bits (string: "") - 이 CA에 대해 생성할 키의 길이. 공급자가 새 키를 생성할 때만 사용됩니다. Consul 공급자에 대해 private_key가 설정되거나 Vault에 기존 루트 또는 중간 PKI 경로가 주어지면 무시됩니다.현재 지원되는 값은 다음과 같습니다.
- private_key_type = ec (기본값): 같은 이름의 NIST P-* 곡선에 해당하는 224, 256, 384, 521.
- private_key_type = rsa: 2048, 4096

제한 사항 (Limitations)

ACM Private CA에는 인증서가 발급될 수 있는 속도를 제한하는 몇 가지 한도가 있습니다. 이는 대규모 클러스터가 발급된 모든 인증서를 교체할 수 있는 속도에 영향을 줄 수 있습니다.

현재 서비스 메시용 ACM Private CA 공급자에는 아래에 설명된 몇 가지 추가 제한 사항이 있습니다.

다른 CA 교차 서명 불가

마이그레이션 중에 다른 CA 공급자의 루트 인증서를 교차 서명하는 것은 불가능합니다. ACM Private CA는 다른 워크플로우를 통해 이를 수행할 수 있지만 CSR이 생성되지 않으면 다른 루트 인증서를 맹목적으로 교차 서명할 수 없습니다. Consul의 내장 CA와 Vault는 모두 이를 수행할 수 있으며 CA를 관리하는 현재 워크플로우는 이에 의존합니다.

현재 이 제한은 ACM Private CA가 CA 공급자로 구성되면 다른 CA 공급자를 재구성하거나 일시적인 연결 실패를 관찰하지 않고 루트 CA 키를 교체하는 것이 불가능함을 의미합니다. 자세한 내용은 forced rotation without cross-signing 섹션을 참조하세요.

기본 DC는 루트 CA여야 함

현재 기존 ACM Private CA를 사용하면 기본 DC는 인증서를 발급하기 위해 루트 CA를 직접 사용해야 합니다.

비용 계획 (Cost Planning)

비용 추정을 돕기 위해 사용될 리소스의 예시가 아래 제공됩니다.

이것은 비용 계획 목적의 CA 동작을 설명하기 위한 것입니다. 실제 비용 정보는 ACM Private CA 가격을 참조하세요.

다음 Consul 데이터센터가 존재하고 기본 리프 인증서 수명 72시간으로 ACM Private CA를 서비스 메시 CA로 사용하도록 구성되었다고 가정합니다.

| 데이터센터 | 기본 | 생성된 CA 리소스 | 서비스 인스턴스 수 | | dc1 | yes | 1 ROOT | 100 | | dc2 | no | 1 SUBORDINATE | 50 | | dc3 | no | 1 SUBORDINATE | 500 |

리프 인증서는 72시간 동안 유효하지만 수명의 60%에서 90% 사이가 경과하면 새로 고쳐집니다. 평균적으로 각 인증서는 54시간마다 또는 대략 월 13.3회 재발급됩니다.

따라서 월간 비용은 다음과 같이 계산됩니다.

3 ⨉ 월간 CA 비용, 더하기
8630 ⨉ 인증서 발급 비용, 구성:
- 100 ⨉ 13.3 = dc1에서 발급된 1,330 인증서
- 50 ⨉ 13.3 = dc2에서 발급된 665 인증서
- 500 ⨉ 13.3 = dc3에서 발급된 6,650 인증서

더 긴 수명의 자격 증명이 비용에 대한 허용 가능한 위험 트레이드오프라면 CA Provider 구성에서 leaf_cert_ttl을 늘려 발급되는 인증서 수를 줄일 수 있습니다.

AWS Certificate Manager