Apigee Hybrid의 서비스 계정 인증 방법

Apigee Hybrid에서 서비스 계정 인증 방법 선택

Apigee Hybrid는 Google Cloud 서비스와의 보안 통신을 위해 서비스 계정이 필요합니다. 보안 및 운영 요구사항에 부합하는 서비스 계정의 인증 방법을 선택합니다. 이 가이드에서는 사용 가능한 옵션을 간략하게 설명합니다.

서비스 계정 인증 이해

Apigee Hybrid는 Google Cloud 서비스 계정을 사용하여 Kubernetes 클러스터에서 실행되는 구성요소를 인증하고 승인합니다. 이러한 서비스 계정은 Cloud Storage 버킷 및 Cloud Logging과 같은 리소스에 액세스합니다. Google Cloud 각 서비스 계정에는 기능을 수행하기 위한 특정 Identity and Access Management (IAM) 역할이 필요합니다.

인증 방법 옵션

Apigee Hybrid는 서비스 계정을 인증하는 여러 방법을 지원합니다. 각 방법은 서비스 계정 키를 다르게 관리하여 다양한 수준의 보안과 운영 복잡성을 제공합니다. 방법을 선택할 때는 플랫폼, 보안 상황, 기존 인프라를 고려하세요.

다음 표에는 사용 가능한 인증 방법이 요약되어 있습니다.

메서드 키 저장 위치 플랫폼 호환성 키 관리
Kubernetes 보안 비밀 Kubernetes 클러스터 보안 비밀 모든 Kubernetes 플랫폼 Kubernetes에서 보안 비밀 관리, 수동 순환
서비스 계정 JSON 키 파일 로컬 파일 시스템 모든 Kubernetes 플랫폼 수동 로테이션 및 배포
Vault HashiCorp Vault 모든 Kubernetes 플랫폼 Vault에서 보안 비밀 관리, 수동 순환
GKE용 워크로드 아이덴티티 제휴 Google Cloud IAM Google Kubernetes Engine(GKE) Google Cloud 에서 관리, 키 파일 불필요
다른 플랫폼의 워크로드 아이덴티티 제휴 Google Cloud IAM AKS, EKS, OpenShift 또는 기타 Kubernetes 플랫폼 Google Cloud 에서 관리, 키 파일 불필요

Kubernetes 보안 비밀에 서비스 계정 키 저장

클러스터 내에 서비스 계정 키를 Kubernetes 보안 비밀로 저장합니다. 이 메서드는 Kubernetes의 기본 제공 보안 비밀 관리 기능을 활용합니다. Kubernetes 보안 비밀은 직접 파일 저장보다 키를 더 안전하게 관리할 수 있는 방법을 제공합니다. 키 순환은 여전히 수동으로 관리합니다.

하이브리드 구성요소는 overrides.yaml 파일의 serviceAccountRef 및 envs[].serviceAccountRefs 속성을 사용하여 이러한 보안 비밀을 참조합니다. Kubernetes는 이러한 보안 비밀을 적절한 포드에 배포하는 것을 관리합니다.

예를 들면 다음과 같습니다.

logger:
  serviceAccountRef: "my-project-apigee-logger-key"

이 방법을 사용하려면 Kubernetes 보안 비밀에 서비스 계정 키 저장을 참고하세요.

서비스 계정 JSON 키 파일

이 방법은 각 서비스 계정에 대해 JSON 키 파일을 만들고 이러한 파일을 파일 시스템에 직접 저장하는 방식입니다. 이 접근 방식은 초기 설정을 간소화합니다. 하지만 파일 시스템의 보안을 보장해야 합니다. 키 순환은 수동입니다.

각 서비스 계정의 비공개 키 JSON 파일을 Apigee 하이브리드 구성요소에서 액세스할 수 있는 디렉터리에 배치합니다. serviceAccountPath 및 envs[].serviceAccountPaths 속성을 사용하여 overrides.yaml 구성에서 이러한 파일의 경로를 참조합니다.

예를 들면 다음과 같습니다.

logger:
  serviceAccountPath: "my-project-apigee-logger.json"

Apigee Hybrid와 함께 제공되는 create-service-account 도구를 사용하여 서비스 계정 키 파일을 생성하고 다운로드할 수 있습니다. 자세한 내용은 create-service-account를 참조하세요.

Vault에 서비스 계정 키 저장

HashiCorp Vault를 통합하여 서비스 계정 키를 관리합니다. Vault는 보안 비밀 관리를 위한 강력한 솔루션을 제공하며 동적 보안 비밀 생성, 감사, 자동 키 순환과 같은 기능을 제공합니다. Vault 인스턴스를 설정하고 유지해야 합니다.

조직 수준 및 환경 수준 구성요소에 대해 별도의 Vault 보안 비밀, 정책, 역할을 만들어야 합니다. serviceAccountSecretProviderClass 및 envs[].serviceAccountSecretProviderClass 속성을 사용하여 overrides.yaml 구성에서 이러한 비밀을 참조합니다.

예를 들면 다음과 같습니다.

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

envs:
- name: my-env
  serviceAccountSecretProviderClass: apigee-envsakeys-my-env-spc

Vault에 서비스 계정 키 저장을 참고하세요.

GKE용 워크로드 아이덴티티 제휴

GKE용 워크로드 아이덴티티 제휴를 사용하면 Kubernetes 서비스 계정이 Google Cloud서비스 계정으로 작동할 수 있습니다. 이 방법을 사용하면 서비스 계정 키 파일이 완전히 필요하지 않습니다. 대신 GKE 클러스터에서Google Cloud IAM을 사용하여 워크로드를 직접 인증합니다. GKE용 워크로드 아이덴티티 제휴는 매우 안전하고 자동화된 인증 메커니즘을 제공하여 키 관리를 간소화합니다. 이 메서드는 GKE 클러스터에만 적용됩니다.

이 메서드를 사용하려면 각 Kubernetes 서비스 계정을 특정 Google Cloud 서비스 계정에 바인딩해야 합니다. Apigee Hybrid 설치 프로세스는 Apigee Hybrid Helm 차트를 설치할 때 설치에 맞는 Kubernetes 서비스 계정을 만듭니다. 각 차트에 --dry-run 플래그를 사용하여 helm install 또는 helm upgrade 명령어를 실행하면 해당 차트의 특정 Apigee Hybrid 구성요소에 대한 Kubernetes 서비스 계정을 Google Cloud 서비스 계정에 바인딩하는 명령어가 출력에 포함됩니다.

gcp.workloadIdentity.enabled 속성을 사용하여 overrides.yaml 파일에서 GKE용 워크로드 아이덴티티 제휴를 사용 설정합니다.

예를 들면 다음과 같습니다.

gcp:
  projectID: my-project
  region: us-west1
  workloadIdentity:
    enabled: true

GKE용 워크로드 아이덴티티 제휴 사용 설정을 참고하세요.

GKE 이외 플랫폼의 워크로드 아이덴티티 제휴

워크로드 아이덴티티 제휴는 GKE용 워크로드 아이덴티티 제휴의 이점을 Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), OpenShift와 같이 Google Cloud외부에서 실행되는 Kubernetes 클러스터로 확장합니다. 이 방법을 사용하면 클러스터의 OIDC 공급자를 사용하여 Google Cloud 에 인증하고 클러스터의 ID 공급자와 Google Cloud간의 신뢰 관계를 구성할 수 있습니다. 초기 설정 후 이 메서드는 서비스 계정 키 파일이 필요하지 않습니다.

워크로드 아이덴티티 제휴는 다음 항목과 함께 사용할 수 있습니다.

  • 사용자 인증 정보 구성 파일 (서비스 계정 키 파일 대신)
  • Kubernetes 보안 비밀
  • Vault

워크로드 아이덴티티 제휴를 사용하려면 각 Google Cloud 서비스 계정에 대한 사용자 인증 정보 구성 파일을 만듭니다. 이러한 파일은 서비스 계정 키 파일 대신 사용하거나 이러한 방법을 사용하는 경우 Kubernetes 보안 비밀 또는 Vault를 설정하는 데 사용됩니다.

override.yaml 파일에서 gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience, gcp.federatedWorkloadIdentity.credentialSourceFile 속성을 사용하여 워크로드 아이덴티티 제휴를 사용 설정합니다.

예를 들면 다음과 같습니다.

gcp:
  projectID: my-project
  region: us-west1
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

워크로드 아이덴티티 제휴 사용 설정을 참고하세요.

인증 방법 선택

배포 환경 및 보안 요구사항에 따라 인증 방법을 선택합니다.

  • GKE 배포의 경우 GKE용 워크로드 아이덴티티 제휴는 안전하고 간소화된 접근 방식을 제공합니다. 서비스 계정 키 파일을 직접 관리할 필요가 없습니다.
  • GKE 이외의 Kubernetes 배포 (AKS, EKS, OpenShift)의 경우 워크로드 아이덴티티 제휴가 유사한 키 없는 인증 환경을 제공합니다. 이 메서드는 이러한 환경에 권장되는 선택사항입니다.
  • GKE용 워크로드 아이덴티티 제휴 또는 워크로드 아이덴티티 제휴가 옵션이 아닌 경우 Vault를 사용하여 중앙 집중식 키 관리 및 자동화를 고려하세요.
  • 배포를 간소화하거나 Vault 설정이 없는 경우 Kubernetes 보안 비밀에 키를 저장하면 네이티브 Kubernetes 솔루션을 사용할 수 있습니다. 이 방법은 직접 파일 저장보다 더 나은 보안을 제공합니다.
  • 직접 서비스 계정 키 파일은 초기 테스트 또는 다른 방법을 사용할 수 없는 환경에 적합합니다. 하지만 이 방법은 신중한 수동 키 관리 및 순환이 필요합니다.

다음 단계