사용자 클러스터에서 OIDC 인증 구성

이 페이지는 플랫폼 관리자용으로 작성되었습니다.

이 페이지에서는 사용자 클러스터에서 OpenID Connect(OIDC) 인증을 사용 설정하고 역할 기반 액세스 제어(RBAC)를 설정하는 방법을 설명합니다. OIDC를 사용한 인증에 대한 자세한 내용은 Anthos clusters on bare metal에서 OIDC를 사용한 ID 관리를 참조하세요.

사용자 클러스터에서 OIDC 인증 사용 설정

사용자 클러스터를 만드는 동안 또는 기존 사용자 클러스터에서 OIDC 인증을 사용 설정할 수 있습니다. OIDC 인증을 설정할 때의 전제조건은 클러스터에 적용할 ID 프로필이 존재해야 한다는 것입니다. ID 프로필 만들기를 참조하세요.

클러스터 만들기 중 ID 프로필 설정

Anthos 관리 센터 콘솔에서 사용자 클러스터를 만드는 방법은 사용자 클러스터 만들기를 참조하세요. 클러스터 구성 페이지에서 사용자 클러스터를 만들려면 AIS 구성 드롭다운 목록에서 ID 프로필을 선택합니다. 이러한 ID 프로필은 사용자 클러스터에 적용됩니다.

클러스터 만들기 중 ID 프로필 적용

기존 사용자 클러스터에 ID 프로필 설정

ID 및 액세스 페이지로 이동합니다.
클러스터에 프로필 적용을 클릭합니다.
프로필 드롭다운 목록에서 적용할 ID 프로필을 선택합니다.
클러스터 드롭다운 목록에서 ID 프로필을 적용할 클러스터를 선택합니다.

사용자 클러스터에 적용된 ID 프로필 보기

사용자 클러스터에 적용된 ID 프로필은 ID 및 액세스 페이지에서 볼 수 있습니다.

클러스터 탭을 선택하고, 확인할 사용자 클러스터를 찾은 후 해당 사용자 클러스터에 대해 구성 세부정보 보기를 클릭합니다.

사용자 클러스터 ID 구성 보기

사용자 클러스터 로그인 구성 다운로드

구성 세부정보 보기 슬라이드 아웃 페이지에서 로그인 구성 다운로드를 클릭합니다.

파일에서 OIDC 구성 지정

다음 콘텐츠가 포함된 파일을 만듭니다. 이 파일을 user-cluster-oidc-config.yaml로 저장합니다.

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos running in
      # disconnected mode, so a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

다음을 바꿉니다.

CONFIGURATION_NAME: 만들려는 OIDC 구성의 이름입니다.
CLIENT_ID: OpenID 제공업체에 인증을 요청하는 클라이언트 애플리케이션의 ID입니다.
CLIENT_SECRET: 클라이언트 애플리케이션의 보안 비밀입니다.
EXTRA_PARAMS: OpenID 제공업체에 전송할 추가적인 키-값 매개변수(쉼표로 구분)입니다.
ISSUER_URI: 승인 요청이 OpenID에 전송되는 URL입니다.
SCOPES: OpenID 제공업체에 전송할 추가 범위(쉼표로 구분)입니다.
USER_CLAIM: 사용자 이름으로 사용할 JWT 클레임입니다. OpenID 제공업체에 따라 이메일 또는 이름과 같은 다른 클레임을 선택할 수 있습니다. 하지만 이메일 이외의 클레임은 이름 충돌을 방지하기 위해 발급기관 URL이 프리픽스로 추가됩니다.
GROUPS_CLAIM: OIDC ID 토큰에서 사용자의 그룹 정보가 저장된 클레임의 이름입니다.
CERT_AUTHORITY_DATA: OIDC 제공업체에 대해 base64로 인코딩된 선택사항인 PEM 인코딩 인증서입니다. 필요하지 않으면 삭제합니다. 문자열을 만들려면 헤더를 포함한 인증서를 base64로 인코딩합니다. certificateAuthorityData에 결과 문자열을 단일 줄로 포함합니다.

원하는 구성으로 파일을 수정한 후 다음 명령어를 실행합니다.

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

다음을 바꿉니다.

USER_CLUSTER_KUBECONFIG: 사용자 클러스터 Kubeconfig 파일의 경로입니다.
OIDC_CONFIG: 만든 구성 파일의 경로입니다.

사용자 클러스터에서 RBAC 설정

이 섹션에서는 개별 네임스페이스에 대해 액세스 권한을 부여하기 위해 RBAC를 설정하는 방법에 대한 예시를 제공합니다. 자세한 내용은 Kubernetes RBAC 문서를 참조하세요.

workload-a 및 workload-b라는 2개의 네임스페이스가 있다고 가정합니다. 네임스페이스 workload-a의 리소스를 사용자 alice@example.com이 읽고 쓸 수 있고 workload-b의 리소스를 사용자 bob@example.com이 읽을 수 있도록 하기 위해서입니다. alice@example.com은 workload-b에 액세스할 수 없고 bob@example.com은 workload-a에 액세스할 수 없습니다.

사용자 클러스터에서 네임스페이스를 만듭니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

각 네임스페이스에 대한 액세스를 제한하려면 각 네임스페이스에 대한 권한을 정의해야 합니다. Kubernetes에서는 역할을 만들어 이 작업을 수행할 수 있습니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

foo-full-access에 대해 정의된 verbs는 이 역할이 네임스페이스에서 수행할 수 있는 모든 작업을 정의합니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

b-read-access의 경우 정의된 verbs는 역할이 리소스를 쿼리하는 것만 허용합니다.

사용자에게 권한을 부여하려면 RoleBindings를 만들어야 합니다. RoleBinding에는 개별 사용자뿐만 아니라 그룹도 포함될 수 있습니다. 이 예시에서는 개별 사용자를 보여줍니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: prefix-alice@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

위의 RoleBinding(a-full-access-users)은 사용자 alice@example.com에게 a-full-access 역할에 정의된 권한을 부여합니다. 즉, 사용자 alice@example.com은 workload-a 네임스페이스의 리소스를 읽고 쓸 수 있습니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: bob@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

이 RoleBinding(b-read-access-users)은 사용자 bob@example.com에게 b-read-access 역할에 정의된 권한을 부여합니다. 따라서 사용자 bob@example.com은 workload-b 네임스페이스의 리소스만 읽을 수 있습니다.

OIDC 제공업체로 로그인

사용자 클러스터의 관리자로서 사용자 클러스터의 모든 사용자가 로그인할 때 사용할 로그인 구성 파일을 가져옵니다. Anthos 관리 센터에서 로그인 구성을 가져오려면 사용자 클러스터 로그인 구성 파일 다운로드를 참조하세요. 또는 다음을 실행하여 로그인 구성 파일을 만들 수 있습니다.

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

사용자 클러스터 사용자에게 USER_CLUSTER_NAME-actl-auth-login-config.yaml을 배포합니다.

OIDC 공급자로 인증하고 명령줄의 안내를 따르세요.

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

USER_CLUSTER_NAME을 관리 콘솔에 표시되는 사용자 클러스터의 이름으로 바꿉니다. --kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig는 출력 Kubeconfig 파일 이름입니다. CONFIGURATION_NAME을 인증할 ID 프로필 이름으로 바꿉니다. USER_CLUSTER_NAME-actl-auth-login-config.yaml을 열어 프로필 이름을 확인합니다.

다음과 같이 kubectl을 사용하여 새 Kubeconfig를 사용합니다.

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

다음 단계

감사 로그 보기 자세히 알아보기