Envoy SDS api

https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret

Secret discovery service (SDS) — envoy 1.20.0-dev-24845d documentation

 

아래는 허접 번역..

Secret discovery service (SDS)

TLS 인증서, 시크릿은 bootstrap.static_resource secrets에 명시될 수 있다. 하지만 secret discovery service (SDS)를 이용해 원격으로 가져올 수(fetch)도 있다.

SDS의 가장 중요한 이점(benefit)은 인증서 관리를 단순화하는 것이다. 이 기능이 없으면 k8s 배포할 때 인증서를 시크릿으로 생성되어야 하고 proxy 컨테이너에 탑재(mount)되어야 한다. 인증서가 만료되면 시크릿을 업데이트해야 하고 proxy 컨테이너를 다시 배포해야 한다. SDS를 사용하면 중앙(central) SDS 서버가 모든 Envoy 인스턴스에 인증서를 푸시하게 된다. 인증서가 만료되면, 서버는 새 인증서를 Envoy 인스턴스에 푸시하고 Envoy는 다시 배포하지 않고 새 인증서를 즉시 사용하게 된다.

Listener 서버 인증서를 SDS를 이용해 원격으로 가져올 필요가 있으면, 인증서를 Active로 설정되지 않고, 인증서를 가져오기 전에 해당 포트가 열리지 않는다. Envoy가 연결 실패 또는 잘못된 응답 데이터로 인해 인증서를 가져오지 못하면, listener는 active로 표시되고 포트는 열리지만 포트에 대한 연결은 reset될 것이다.

upstream 클러스터도 비슷한 방식으로 동작하는데, SDS를 이용해 원격으로 클러스터 클라이언트 인증서를 가져와야 하는 경우, active로 표시되지 않으며 인증서를 가져오기 전에 사용되지 않는다. Envoy가 연결 실패 또는 잘못된 응답 데이터로 인해 인증서를 가져오지 못하면, 클러스터가 active로 표시되고 요청을 처리하는 데 사용할 수 있지만 해당 클러스터로 라우팅된 요청은 거부될 것이다.

정적 클러스터가 SDS를 사용 중이고 SDS 클러스터를 정의해야 하는 경우(클러스터가 필요하지 않은 Google gRPC를 사용하지 않는 한) SDS 클러스터를 사용하는 정적 클러스터보다 먼저 SDS 클러스터를 정의해야 한다.

Envoy proxy와 SDS 서버 간의 연결은 안전해야 한다. 한 가지 옵션은 동일한 호스트에서 SDS 서버를 실행하고 연결에 Unix Domain 소켓을 사용하는 것이다. 그렇지 않으면 연결에 proxy와 SDS 서버 간의 인증(authentication)된 TLS (TLS with authentication)가 필요하다. 오늘날 인증에 사용되는 자격 증명(credential) 유형은 다음과 같다:

• mTLS – 이 경우 SDS 연결을 위한 클라이언트 인증서를 정적으로 구성해야 한다.
• AWS IAM SigV4

SDS server

SDS 서버는 gRPC 서비스 SecretDiscoveryService를 구현할 필요가 있다. 이는 다른 xDS처럼 동일한 프로토콜을 이용하게 된다.

SDS Configuration

SdsSecretConfig는 시크릿을 지정하는 데 사용된다. 해당 필드 이름은 필수 필드이다. sds_config 필드가 비어 있는 경우 이름 필드는 bootstrap static_resource 시크릿에 있는 시크릿을 명시한다. 그렇지 않으면 SDS 서버를 ConfigSource로 지정한다. SDS 서비스에는 gRPC만 지원되므로 해당 api_config_source는 grpc_service를 지정해야만 한다.

SdsSecretConfig는 CommonTlsContext의 두 필드에서 사용된다. 첫 번째 필드는 tls_certificate_sds_secret_configs로, SDS를 사용하여 TlsCertificate를 가져오는 위함이다. 두 번째 필드는 validation_context_sds_secret_config로, SDS를 사용하여 CertificateValidationContext를 가져오기 위함이다.

Key rotation

일반적으로 gRPC SDS를 통해 key rotation을 수행하는 것이 바람직하다. 하지만 이것이 불가능하거나 사용하기 원하는 경우(예: SDS 자격 증명의 bootstrip 중), 시크릿이 파일 시스템 경로를 가리킬 때 SDS는 파일 시스템 rotation을 허용한다. 현재 이것은 다음 시크릿 유형을 지원한다:

• TlsCertificate
• CertificateValidationContext

기본적으로 시크릿이 포함된 디렉토리는 파일 시스템 이동 이벤트에 대해 감시가 된다. 예를 들어 /foo/bar/baz/cert.pem의 key 또는 신뢰할 수 있는 CA 인증서는 /foo/bar/baz 에 대해 감시된다. 감시되는 디렉터리에 대한 명시적 제어는 TlsCertificate 및 CertificateValidationContext에 watched_directory 경로를 지정하면 가능하다. 이를 통해 선행 경로 예를 들면 /foo/bar 에서 감시를 설정할 수 있다. 이는 공통 키 rotation schme을 구현할 때 유용하다.

key rotation의 예를 below에서 확인할 수 있다.

 

예제는... 해당 페이지에서 참조...

 

 

Statistics

SSL socket factory 출력은 SDS 관련 통계에 따른다. 모두 카운터 타입.

downstream listener의 경우, 이는 listener.<LISTENER_IP>.server_ssl_socket_factory namespace 에 있다.

NameDescription

ssl_context_update_by_sds	ssl context의 총 수가 업데이트된다
downstream_context_secrets_not_ready	ssl 인증서가 없어서 reset된 downstream 연결의 총 수

upstream cluster의 경우, 이는 cluster.<CLUSTER_NAME>.client_ssl_socket_factory.namespace. 에 있다.

NameDescription

ssl_context_update_by_sds	ssl context의 총 수가 업데이트된다
upstream_context_secrets_not_ready	ssl 인증서가 없어서 reset된 upstream 연결의 총 수

SDS 는 sds.<SECRET_NAME>. namespace 에  statistics tree 를 가지고 있다. 추가적으로 다음 통계들이 이 namespace에서 체크(track)된다:

NameDescription

key_rotation_failed

SDS 업데이트 이외(outside of an SDS update)에 실패한 filesystem key rotations의 총 수