이 페이지는 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 콘솔 프로젝트
- HTTPS 부하 분산기로 제공된 하나 이상의 GKE 인스턴스 그룹. 부하 분산기는 GKE 클러스터에서 Ingress 객체를 만들 때 자동으로 생성됩니다.
- HTTPS용 Ingress 만들기에 대해 자세히 알아보세요.
- 부하 분산기 주소에 등록된 도메인 이름
- 모든 요청에 ID가 포함되었는지 확인하기 위한 애플리케이션 코드
- 사용자의 ID 가져오기에 대해 자세히 알아보세요.
IAP 사용 설정
If you haven't configured your project's OAuth consent screen, you'll be prompted to do so. To configure your OAuth consent screen, see Setting up your OAuth consent screen.
If you are running GKE clusters version 1.24 or later, you can configure
IAP and GKE by using the Kubernetes Gateway API. To do so, complete
the following steps and then follow the instructions in
Configure IAP.
Do not configure BackendConfig
.
Setting up IAP access
-
Go to the
Identity-Aware Proxy page.
Go to the Identity-Aware Proxy page - Select the project you want to secure with IAP.
-
Select the checkbox next to the resource you want to grant access to.
If you don't see a resource, ensure that the resource is created and that the BackendConfig Compute Engine ingress controller is synced.
To verify that the backend service is available, run the following gcloud command:
gcloud compute backend-services list
- On the right side panel, click Add principal.
-
In the Add principals dialog that appears, enter the email addresses of groups or
individuals who should have the IAP-secured Web App User role for the project.
The following kinds of principals can have this role:
- Google Account: user@gmail.com
- Google Group: admins@googlegroups.com
- Service account: server@example.gserviceaccount.com
- Google Workspace domain: example.com
Make sure to add a Google Account that you have access to.
- Select Cloud IAP > IAP-secured Web App User from the Roles drop-down list.
- Click Save.
Configuring BackendConfig
To configure BackendConfig for IAP, create a Kubernetes Secret and then
add an iap
block to the BackendConfig.
Creating a Kubernetes Secret
The BackendConfig uses a Kubernetes
Secret
to wrap the OAuth client you created earlier. Kubernetes Secrets are managed like
other Kubernetes objects by using the
kubectl
command-line interface (CLI). To create a Secret, run the following command where
client_id_key and client_secret_key are the keys from the JSON file you
downloaded when you created OAuth credentials:
kubectl create secret generic my-secret --from-literal=client_id=client_id_key \ --from-literal=client_secret=client_secret_key
The preceding command displays output to confirm when the Secret is successfully created:
secret "my-secret" created
Adding an iap
block to the BackendConfig
To configure the BackendConfig for IAP, you need to specify the
enabled
and secretName
values. To specify these values, ensure
that you have the compute.backendServices.update
permission and add the
iap
block to BackendConfig. In this block, my-secret is
the Kubernetes Secret name you created previously:
For GKE versions 1.16.8-gke.3 and higher, use the `cloud.google.com/v1` API version. If you are using an earlier GKE version, use `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
You also need to associate Service ports with your BackendConfig to trigger turning on IAP. One way to make this association is to make all ports for the service default to your BackendConfig, which you can do by adding the following annotation to your Service resource:
metadata: annotations: beta.cloud.google.com/backend-config: '{"default": "config-default"}'
To test the configuration, run kubectl get event
. If you see the message
"no BackendConfig for service port exists
", then you successfully
associated a service port with your BackendConfig, but the BackendConfig
resource wasn't found. This error can occur if you haven't created the BackendConfig resource,
created it in the wrong namespace, or misspelled the reference in the Service annotation.
If the secretName
you referenced doesn't exist or isn't structured
properly, one of the following error messages will display:
-
BackendConfig default/config-default is not valid: error retrieving secret "foo": secrets "foo" not found.
To resolve this error, make sure that you've created the Kubernetes Secret correctly as described in the previous section. -
BackendConfig default/config-default is not valid: secret "foo" missing client_secret data.
To resolve this error, make sure that you've created the OAuth credentials correctly. Also, make sure that you referenced the correctclient_id
andclient_secret
keys in the JSON you downloaded previously.
When the enabled
flag is set to true
and
the secretName
is correctly set, IAP is configured
for your selected resource.
Turning IAP off
To turn IAP off, you must set enabled
to
false
in the BackendConfig. If you delete the IAP
block from BackendConfig, the settings will persist. For example, if IAP is
enabled with secretName: my_secret
and you delete the block, then
IAP will still be turned on with the OAuth credentials stored in
my_secret
.