GKE에 IAP 사용 설정

이 페이지는 IAP(Identity-Aware Proxy)로 Google Kubernetes Engine(GKE) 인스턴스를 보호하는 방법을 설명합니다.

개요

IAP는 GKE용 인그레스를 통해 통합됩니다. 이 통합을 통해 VPN을 사용하지 않고 직원의 리소스 수준 액세스를 제어할 수 있습니다.

GKE 클러스터에서 들어오는 트래픽은 Cloud Load Balancing의 구성요소인 HTTP(S) 부하 분산에 의해 처리됩니다. HTTP(S) 부하 분산기는 일반적으로 Kubernetes 인그레스 컨트롤러로 구성됩니다. 인그레스 컨트롤러는 하나 이상의 서비스 객체와 연결된 Kubernetes 인그레스 객체에서 구성 정보를 가져옵니다. 각 서비스 객체는 들어오는 요청을 특정 Pod 및 포트로 보내기 위해 사용되는 라우팅 정보를 포함합니다.

Kubernetes 버전 1.10.5-gke.3부터는 서비스를 BackendConfig 객체와 연결하여 부하 분산기에 대한 구성을 추가할 수 있습니다. BackendConfig는 kubernetes/ingress-gce 저장소에 정의된 CRD(커스텀 리소스 정의)입니다.

Kubernetes Ingress 컨트롤러는 BackendConfig에서 구성 정보를 읽고 그에 따라 부하 분산기를 설정합니다. BackendConfig는 Cloud Load Balancing과 관련된 구성 정보를 갖고 있으며, 이를 통해 개발자가 각 HTTP(S) 부하 분산 백엔드 서비스에 대해 별도의 구성을 정의할 수 있습니다.

시작하기 전에

GKE용 IAP를 사용 설정하려면 다음이 필요합니다.

  • 결제가 사용 설정된 Google Cloud Console 프로젝트
  • HTTPS 부하 분산기로 제공된 하나 이상의 GKE 인스턴스 그룹. 부하 분산기는 GKE 클러스터에서 Ingress 객체를 만들 때 자동으로 생성됩니다.
  • 부하 분산기 주소에 등록된 도메인 이름
  • 모든 요청에 ID가 포함되었는지 확인하기 위한 애플리케이션 코드

IAP 사용 설정

프로젝트의 OAuth 동의 화면을 구성하지 않았으면, 구성하라는 메시지가 표시됩니다. OAuth 동의 화면을 구성하려면 OAuth 동의 화면 설정을 참조하세요.

IAP 액세스 설정

  1. Identity-Aware Proxy 페이지로 이동합니다.
    IAP(Identity-Aware Proxy) 페이지로 이동
  2. IAP로 보호하려는 프로젝트를 선택합니다.
  3. 액세스 권한을 부여할 리소스 옆에 있는 체크박스를 선택합니다.

    리소스가 표시되지 않으면 리소스가 생성되었고 BackendConfig Compute Engine 인그레스 컨트롤러가 동기화되었는지 확인합니다.

    백엔드 서비스를 사용할 수 있는지 확인하려면 다음 gcloud 명령어를 실행합니다.

    gcloud compute backend-services list
  4. 오른쪽 패널에서 주 구성원 추가를 클릭합니다.
  5. 표시된 주 구성원 추가 대화상자에서 프로젝트에 대한 IAP 보안 웹 앱 사용자 역할이 있어야 하는 그룹 또는 개별 사용자의 이메일 주소를 입력합니다.

    다음과 같은 종류의 주 구성원이 이 역할을 가질 수 있습니다.

    • Google 계정: user@gmail.com
    • Google 그룹: admins@googlegroups.com
    • 서비스 계정: server@example.gserviceaccount.com
    • Google Workspace 도메인: example.com

    액세스 권한이 있는 Google 계정을 추가해야 합니다.

  6. 역할 드롭다운 목록에서 Cloud IAP > IAP 보안 웹 앱 사용자를 선택합니다.
  7. 저장을 클릭합니다.

BackendConfig 구성

BackendConfig를 구성하려면 Kubernetes 보안 비밀을 만든 후 iap 블록을 BackendConfig에 추가합니다.

Kubernetes 보안 비밀 만들기

BackendConfig는 Kubernetes 보안 비밀을 사용하여 이전에 개발자가 만든 OAuth 클라이언트를 래핑합니다. Kubernetes 보안 비밀은 다른 Kubernetes 객체와 같이 kubectl 명령줄 인터페이스(CLI)를 사용하여 관리됩니다. 보안 비밀을 만들려면 다음 명령어를 실행합니다. 여기서 client_id_keyclient_secret_key는 OAuth 사용자 인증 정보를 만들 때 다운로드한 JSON 파일의 키입니다.

kubectl create secret generic my-secret --from-literal=client_id=client_id_key \
    --from-literal=client_secret=client_secret_key

위 명령어는 보안 비밀이 성공적으로 생성되었는지 확인하기 위한 출력을 표시합니다.

secret "my-secret" created

BackendConfig에 iap 블록 추가

IAP용 BackendConfig를 구성하려면 enabledsecretName 값을 지정해야 합니다. 이 값을 지정하려면 compute.backendServices.update 권한이 있는지 확인하고 iap 블록을 BackendConfig에 추가합니다. 이 블록에서 my-secret는 이전에 만든 Kubernetes 보안 비밀 이름입니다.

GKE 버전 1.16.8-gke.3 이상에서는 `cloud.google.com/v1` API 버전을 사용합니다. 이전 GKE 버전을 사용하는 경우 `cloud.google.com/v1beta1`을 사용합니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: config-default
  namespace: my-namespace
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

또한 IAP 사용 설정을 트리거하려면 서비스 포트를 BackendConfig와 연결해야 합니다. 이 연결을 만드는 한 가지 방법은 서비스의 모든 포트를 BackendConfig로 기본 설정하는 것입니다. 서비스 리소스에 다음 주석을 추가하여 수행할 수 있습니다.

metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "config-default"}'

구성을 테스트하려면 kubectl get event를 실행하세요. 'no BackendConfig for service port exists' 메시지가 표시되면 서비스 포트를 BackendConfig와 성공적으로 연결했지만 BackendConfig 리소스를 찾지 못한 것입니다. 이 오류는 BackendConfig 리소스를 만들지 않았거나 잘못된 네임스페이스로 만들었거나 서비스 주석에서 참조 철자를 잘못 쓴 경우에 발생할 수 있습니다.

참조한 secretName이 없거나 올바르게 구성되지 않은 경우 다음 오류 메시지 중 하나가 표시됩니다.

  • BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found. 이 오류를 해결하려면 이전 섹션에서 설명한 대로 올바르게 Kubernetes 보안 비밀을 만들었는지 확인합니다.
  • BackendConfig default/config-default is not valid: secret "foo" missing client_secret data. 이 오류를 해결하려면 OAuth 사용자 인증 정보를 올바르게 만들었는지 확인합니다. 또한 이전에 다운로드한 JSON에서 올바른 client_idclient_secret 키를 참조했는지 확인합니다.

enabled 플래그가 true로 설정되고 secretName이 올바르게 설정되면 선택한 리소스에 대해 IAP가 구성됩니다.

IAP 사용 중지

IAP를 사용 중지하려면 BackendConfig에서 enabledfalse로 설정해야 합니다. BackendConfig에서 IAP 블록을 삭제해도 설정은 유지됩니다. 예를 들어 IAP가 secretName: my_secret로 사용 설정된 상태에서 블록을 삭제해도 my_secret에 저장된 OAuth 사용자 인증 정보를 사용하면 IAP가 계속 사용 설정됩니다.

다음 단계