GKE Identity Service의 사용자 액세스 설정

이 문서는 Fleet 수준 GKE Identity Service의 클러스터 구성 또는 OIDC로 GKE Identity Service용 클러스터 구성의 안내를 따라 GKE Identity Service에 클러스터를 이미 구성한 클러스터 관리자를 대상으로 합니다. 여기에서는 조직의 개발자 및 다른 클러스터 사용자를 위해 구성된 클러스터에 대한 액세스를 설정하고 제한하는 방법을 알려줍니다.

사용자 로그인 액세스 설정

클러스터를 구성한 후에는 로그인 구성 파일을 생성하여 클러스터 사용자에게 배포해야 합니다. 이 파일을 사용하면 사용자가 GKE Identity Service로 클러스터에 액세스의 설명대로 선택한 제공업체를 통해 명령줄에서 클러스터에 로그인할 수 있습니다.

OIDC 공급업체만 사용하는 경우 사용자는 또한 Google Cloud 콘솔에서 클러스터 작업의 설명대로 로그인 파일을 사용하지 않고도 Google Cloud 콘솔에서 클러스터에 로그인할 수 있습니다.

로그인 구성 생성

Console

(Fleet 수준 설정 전용)

표시된 gcloud 명령어를 복사하고 실행하여 파일을 생성합니다.

gcloud

gcloud CLI를 사용하여 클러스터를 구성했거나 파일을 다시 생성해야 하는 경우 다음 명령어를 실행하여 파일을 생성합니다.

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

여기서 KUBECONFIG는 클러스터의 kubeconfig 파일 경로입니다. kubeconfig에 여러 컨텍스트가 있으면 현재 컨텍스트가 사용됩니다. 명령어를 사용하기 전 현재 컨텍스트를 올바른 클러스터로 재설정해야 할 수 있습니다.

선택적인 추가 매개변수를 포함하여 이 명령어에 대한 전체 참조 세부정보는 Google Cloud CLI 참조 가이드를 참조하세요.

로그인 구성 파일의 기본 이름은 파일을 사용하여 로그인할 때 Google Cloud CLI에 사용되는 이름인 kubectl-anthos-config.yaml입니다. 이를 기본값이 아닌 이름으로 변경하려면 아래의 로그인 구성 배포에서 관련 섹션을 참조하세요.

사용자 액세스와 관련된 문제 해결 정보는 사용자 액세스 문제 해결을 참조하세요.

로그인 구성 배포

로그인 구성 배포를 위해 사용 가능한 몇 가지 방법은 다음과 같습니다.

  • 액세스 가능한 URL에서 파일을 호스팅합니다. Google Cloud CLI로 파일을 가져올 수 있도록 gcloud anthos auth login을 실행할 때 --login-config 플래그로 이 위치를 지정할 수 있습니다.

    보안 호스트에 파일을 호스팅하는 것이 좋습니다. 보안 HTTPS 액세스에 PEM 인증서를 사용하는 방법에 대한 자세한 내용은 gcloud CLI의 --login-config-cert 플래그를 참조하세요.

  • 로컬 머신에 저장할 위치 정보와 함께 각 사용자에게 파일을 수동으로 제공합니다. 이러한 위치 정보는 Google Cloud CLI가 OS별 기본 위치에서 파일을 찾기 위해 필요합니다. 파일에 기본값이 아닌 이름 또는 위치가 있는 경우 클러스터에 대해 명령어를 실행할 때 사용자가 --login-config 플래그를 사용하여 구성 파일 위치를 지정해야 합니다. 파일 저장 안내는 GKE Identity Service로 클러스터에 액세스를 참조하세요.

  • 내부 도구를 사용하여 인증 구성 파일을 각 사용자 머신으로 푸시합니다. Google Cloud CLI는 사용자 OS에 따라 다음 위치에서 파일을 찾습니다.

    Linux

    $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    macOS

    $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

    Windows

    %APPDATA%\google\anthos\kubectl-anthos-config.yaml

대체 인증 프로세스를 통해 사용자 로그인 액세스 설정

구성 파일을 모든 사용자에게 배포하는 대신 대체 인증 프로세스를 사용하여 사용자 로그인 액세스를 설정할 수 있습니다. 사용자는 정규화된 도메인 이름(FQDN)으로 GKE Identity Service 서버에서 직접 인증할 수 있습니다. SAML 제공업체의 경우 사용자 로그인 액세스는 이 대체 인증 프로세스를 통해서만 지원됩니다.

사용자와 FQDN 공유

클러스터 관리자는 구성 파일 대신 GKE Identity Service 서버의 FQDN을 사용자와 공유할 수 있습니다. 사용자는 이 FQDN을 사용하여 클러스터에 로그인할 수 있습니다. GKE Identity Service 서버 URL은 다음 형식 중 하나로 제공됩니다.

  • https://CLUSTER-SERVER-NAME.com
  • CLUSTER-SERVER-NAME.com

신뢰할 수 있는 SNI 인증서를 사용한 사용자 로그인 액세스

SNI 인증서는 회사 기기에 이미 있는 신뢰할 수 있는 인증서를 활용하여 클러스터 액세스를 간소화합니다. 관리자는 클러스터를 만들 때 이 인증서를 사용합니다. 사용자는 관리자가 제공한 FQDN을 사용하여 클러스터에 로그인해야 합니다. 또는 인증에 성공한 후 토큰이 저장되는 보안 kubeconfig 파일을 사용할 수 있습니다.

다음 명령어를 실행하기 전에 GKE Identity Service 서버에 사용되는 인증서가 사용자 로그인 활동이 수행된 기기에서 신뢰할 수 있는지 확인합니다.

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE

다음을 바꿉니다.

  • APISERVER_URL: GKE Identity Service 서버의 FQDN입니다.
  • OUTPUT_FILE: kubeconfig 파일이 기본 위치 이외의 위치에 있으면 이 플래그를 사용합니다. 이 플래그를 생략하면 인증 토큰이 기본 위치의 kubeconfig 파일에 추가됩니다. 예를 들면 다음과 같습니다. --kubeconfig /path/to/custom.kubeconfig.

클러스터 CA 발급 인증서를 사용한 사용자 로그인 액세스

사용자의 경우 클러스터 수준에서 신뢰할 수 있는 SNI 인증서를 사용하지 않으면 ID 서비스에서 사용하는 인증서가 클러스터의 인증 기관(CA)에서 발급됩니다. 관리자가 이 CA 인증서를 사용자에게 배포합니다. 클러스터의 CA 인증서를 통해 다음 명령어를 실행하여 클러스터에 로그인합니다.

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

역할 기반 액세스 제어(RBAC) 설정

인증은 인증된 사용자 및 서비스 계정에 대해 클러스터에 보다 세분화된 액세스 제어를 제공하기 위해 Kubernetes 역할 기반 액세스 제어(RBAC)와 결합되는 경우가 많습니다. 가능한 모든 경우 사용자 식별자 대신 그룹 이름을 사용하는 RBAC 정책을 만드는 것이 좋습니다. RBAC 정책을 그룹에 명시적으로 연결하면 ID 공급업체를 통해 사용자 액세스 권한을 완전히 관리할 수 있으므로 사용자 권한이 변경될 때마다 클러스터를 업데이트할 필요가 없습니다. 보안 그룹의 멤버십에 따라 액세스 제어를 구성하려면 그룹 멤버십 정보를 가져오도록 GKE Identity Service가 설정되어 있는지 확인해야 합니다.

예를 들어 인증된 특정 사용자가 클러스터의 포드에 액세스할 수 있도록 하려면 다음 예시와 같이 이러한 리소스에 대한 액세스 권한을 부여하는 ClusterRole을 만듭니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["pods"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

그런 후 관련 사용자(여기에서는 us-east1-cluster-admins 보안 그룹의 구성원과 ID u98523-4509823가 있는 사용자)에게 ClusterRole의 권한을 부여하도록 해당 ClusterRoleBinding을 만듭니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-admins
subjects:
  # Grants anyone in the "us-east1-cluster-admins" group
  # read access to Pods in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Grants this specific user read access to Pods in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

다음 예시에서 ClusterRoleBinding은 ID가 12345678-BBBb-cCCCC-0000-123456789012인 관련 그룹에 ClusterRole 권한을 부여합니다. 이 설정은 Azure AD 제공업체에만 관련되며 베어메탈 클러스터용 Google Distributed Cloud Virtual에서 사용할 수 있습니다. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

RBAC 사용에 대한 자세한 내용은 역할 기반 액세스 제어 구성 및 RBAC 승인 사용을 참조하세요.

Google Cloud 콘솔 액세스에 대한 RBAC 역할 만들기

OIDC 제공업체를 사용하여 인증된 사용자는 명령줄뿐만 아니라 Google Cloud 콘솔에서 클러스터에 로그인할 수 있습니다.

Google Cloud 콘솔에서 클러스터 리소스에 액세스하려는 인증된 사용자는 관련 Kubernetes 권한이 있어야 로그인할 수 있습니다. 이러한 사용자에게 클러스터 관리자와 같은 더 광범위한 권한을 부여하지 않으려면 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스를 볼 수 있는 최소 권한이 포함된 커스텀 RBAC 역할을 만들 수 있습니다. 클러스터에 ClusterRole RBAC 리소스, cloud-console-reader를 만들어서 이 권한 집합을 정의할 수 있습니다.

cloud-console-reader는 사용자에게 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스에 대한 get, list, watch 권한을 부여하여 관련 리소스에 대한 세부정보를 볼 수 있게 합니다.

kubectl

cloud-console-reader ClusterRole을 만들고 이를 클러스터에 적용하려면 다음 명령어를 실행합니다.

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

그런 다음 이전 섹션의 설명대로 권한 정책을 설정할 때 사용자에게 ClusterRole을 부여할 수 있습니다. Google Cloud 콘솔에서 클러스터를 보려면 IAM 권한도 필요합니다.