이 가이드는 특정 사용자 그룹에 대한 텔레포트 자격 증명을 발급하는 단일 로그인(Single Sign-On, SSO) 공급자로 Google Workspace를 구성하는 방법을 설명합니다. Google Workspace와 텔레포트의 역할 기반 액세스 제어(RBAC)를 조합하여 다음과 같은 정책을 정의할 수 있습니다:

• "DBA" Google 그룹의 구성원만 PostgreSQL 데이터베이스에 연결할 수 있습니다.
• 개발자는 프로덕션 서버에 SSH로 접근해서는 안 됩니다.

전제 조건

시작하기 전에 다음을 확인하세요:

• Google Workspace 슈퍼 관리자 계정이 있습니다. 관리 작업을 수행하기 위해 다단계 인증이 필요한 별도의 계정을 설정하는 것이 모범 사례입니다. 대부분의 경우, 자신의 로그인 사용자 계정에 관리 권한을 부여하는 것을 피해야 합니다.

• Google Cloud에 가입하고 Google Cloud 프로젝트를 생성할 수 있습니다. 이 가이드는 유료 Google Cloud 서비스를 사용할 필요가 없습니다.

• Google Workspace 그룹을 설정할 수 있습니다.

• oidc 리소스를 유지 관리할 수 있는 텔레포트 역할이 있습니다. 이 권한은 기본 제공된 editor 역할에서 사용할 수 있습니다.

• 텔레포트 클러스터가 있고, 기업 에디션 및 명령줄 도구가 있습니다.

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하기 무료 체험판을 이용해 보세요.

  • tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 16.2.0.

    tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하세요.

• 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오.

  예를 들어:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  클러스터  teleport.example.com
  버전  16.2.0
  CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다.

  자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1단계/4. Google Workspace 구성하기

Google Workspace가 텔레포트와 함께 작동하도록 구성하기 위해서는 다음 단계를 수행해야 합니다:

• Google Workspace 에디션을 검토하여 텔레포트와의 통합 방법을 확인합니다.
• Google Cloud Platform에서 새 프로젝트를 생성합니다.
• 새 프로젝트에 대한 OAuth 동의를 구성합니다.
• 필요한 API를 활성화합니다.
• Google Workspace 사용자가 텔레포트 클러스터에 로그인할 수 있도록 OAuth 클라이언트 ID를 생성합니다.
• 텔레포트가 추가 Google 그룹 정보를 접근할 수 있도록 서비스 계정을 생성합니다.
• 서비스 계정에 대한 도메인 전체 위임을 구성합니다.

Google Workspace 에디션 검토

Google Workspace는 개인 및 조직을 위한 다양한 기능과 기능을 제공하는 여러 에디션으로 제공됩니다. Google Workspace 에디션 간의 차이로 인해 텔레포트가 Google Workspace와 통합되는 방식은 사용하는 Google Workspace 에디션에 따라 근본적으로 다릅니다.

일부 Google Workspace 에디션은 전이 그룹 구성원 자격을 제공합니다. 전이 그룹 구성원 자격이 있으면 사용자는 다른 그룹의 구성원으로 인해 한 그룹의 구성원이 될 수 있습니다. 예를 들어, 부모 그룹 내에 중첩된 자식 그룹이 있는 경우 자식 그룹의 모든 구성원이 부모 그룹의 구성원이 됩니다. 텔레포트는 직접 그룹 구성원 자격과 전이 그룹 구성원 자격을 모두 지원하지만, 서로 다른 방법을 사용합니다.

Google Workspace 에디션 및 API

Google Workspace 서비스 계정은 Google Workspace Cloud Identity API의 메서드를 호출하여 사용자가 특정 그룹에 전이 구성원이 있는지 여부를 확인할 수 있습니다. 이러한 API 메서드는 특정 Google Workspace 에디션에 속하는 사용자에게만 사용 가능합니다.

Google Workspace Directory API는 관리자가 Google Workspace 도메인 내의 사용자 및 그룹을 나열할 수 있도록 하지만, 전이 그룹 구성원 자격을 쿼리할 수 있도록 해주지는 않습니다. Directory API는 모든 Google Workspace 에디션에 대해 사용할 수 있습니다.

텔레포트의 Google Workspace API 사용 방식

텔레포트 OIDC 커넥터는 Google Workspace API를 사용하여 Google Workspace 그룹 구성원을 텔레포트 역할에 매핑합니다.

사용자의 Google Workspace 그룹을 나열하기 위해 텔레포트는 먼저 Cloud Identity API 메서드를 호출하여 자격 증명을 얻으려고 시도합니다. 성공하면, 텔레포트는 자격 증명을 사용하여 사용자의 전이 그룹 구성원 자격을 쿼리합니다.

자격 증명이 존재하지 않으면, 텔레포트는 Directory API 메서드를 호출하여 자격 증명을 얻습니다. 그런 다음 텔레포트는 Directory API를 사용하여 사용자의 전체 Google Workspace에서 사용자가 소속된 그룹을 나열합니다. 사용자가 소속된 그룹 중 작업 공간 외부에 있는 그룹은 나열되지 않습니다.

현재 에디션 확인 방법

Google Workspace 에디션이 전이 그룹 구성원 자격 쿼리를 지원하는지 확인하려면:

1. Google Workspace 관리 콘솔에서 그룹 검사를 엽니다.

   그룹 검사는 Cloud Identity API에 의존합니다.

2. 구성원의 모든 그룹 나열 및 외부 그룹 포함을 선택합니다.

   Google Workspace 에디션이 Cloud Identity API를 지원하면, 작업 공간 수준에서 외부 그룹에 대한 접근을 차단해야 합니다. 그렇지 않으면, 작동 공간 외부의 어떤 그룹의 구성원 자격이 사용자가 로그인하는 것을 방해할 수 있습니다.

   Google Workspace 에디션이 Cloud Identity API를 지원하지 않는 경우, 역할 기반 액세스 제어가 전이 그룹 구성원 자격에 의존하지 않도록 해야 합니다.

새 프로젝트 만들기

기존 Google Cloud 프로젝트에 텔레포트 단일 로그인을 추가하려면 Google Cloud 콘솔에서 해당 프로젝트를 선택하고 이 단계를 건너뛸 수 있습니다. 프로젝트가 없거나 텔레포트를 위해 새 프로젝트를 만들고 싶다면, Enabled APIs & Service 프로젝트 선택기 대시보드로 가서 생성할 수 있습니다.

새 프로젝트를 만들려면:

1. Google Cloud 콘솔을 엽니다.

2. Google Cloud 콘솔 내비게이션 메뉴에서 API 및 서비스를 클릭합니다.

3. 활성화된 API 및 서비스에서 프로젝트 선택기를 클릭한 후 새 프로젝트를 클릭합니다. 대시보드에서 선택할 프로젝트가 없으면 프로젝트 만들기를 클릭합니다.

   

4. 프로젝트 이름을 입력하고 조직 및 프로젝트 위치를 선택한 후 생성을 클릭합니다.

OAuth 동의 구성하기

새 프로젝트의 OAuth 동의를 구성하려면:

1. Google Cloud 콘솔 사이드바에서 OAuth 동의 화면을 클릭합니다.

2. 사용자 유형으로 내부를 선택한 후 생성을 클릭합니다.

   

3. 다음 작업을 수행하여 OAuth 클라이언트 동의 정보를 구성합니다:

   • 애플리케이션 이름을 입력합니다.
   • 사용자의 OAuth 동의에 대한 이메일 메시지를 수신할 사용자 또는 그룹을 선택합니다.
   • 필요에 따라 다른 애플리케이션 옵션을 설정합니다.
   • 프로젝트 변경 시 연락할 개발자 이메일 주소를 제공합니다.

4. 저장하고 계속을 클릭합니다.

5. 범위 추가 또는 제거를 클릭합니다.

6. .../auth/userinfo.email 및 openid 범위를 선택한 후 업데이트를 클릭합니다.

7. 저장하고 계속을 클릭합니다.

8. 요약 페이지의 정보를 검토한 후 대시보드로 돌아가기를 클릭합니다.

필요한 API 활성화하기

OAuth 클라이언트를 위한 필요한 API를 활성화하려면:

1. API 라이브러리에서 Admin SDK API를 선택한 후 활성화를 클릭하여 직접 그룹 구성원을 지원합니다.
2. API 라이브러리에서 Cloud Identity API를 선택한 후 활성화를 클릭하여 전이 그룹 구성원 자격을 지원합니다.

API 라이브러리를 하나 또는 둘 모두 활성화할 수 있습니다. 그러나 선택한 API를 사용하려면 Google Workspace 에디션이 이를 지원해야 합니다. 사용할 수 있는 Google Workspace 에디션에 대해 API 라이브러리의 문서를 참조하시기 바랍니다.

OAuth 클라이언트 ID 만들기

OAuth 클라이언트 식별자를 만들려면:

1. Google Cloud 콘솔 사이드바에서 API 및 서비스를 클릭합니다.

2. API 및 서비스 사이드바에서 자격 증명을 클릭합니다.

3. 자격 증명을 생성하려면 자격 증명 만들기를 클릭하여 만들 수 있는 자격 증명의 목록을 표시합니다.

   

4. OAuth 클라이언트 ID를 선택합니다.

5. 애플리케이션 유형으로 웹 애플리케이션을 선택하고 애플리케이션에 대한 이름을 입력합니다.

6. 인증된 리디렉션 URI 아래에서 URI 추가를 클릭합니다.

7. 리디렉션 URI를 텔레포트 클러스터 주소로 설정한 다음 /v1/webapi/oidc/callback을 URI에 추가합니다.

   

8. 생성을 클릭합니다.

9. 생성된 OAuth 클라이언트에서 클라이언트 ID 및 클라이언트 비밀을 복사하거나 JSON 다운로드를 클릭하여 이 정보를 저장한 후 확인을 클릭합니다.

   클라이언트 식별자와 클라이언트 비밀을 저장하기 위해 JSON 다운로드를 클릭하는 경우, 이 JSON 파일은 인증을 위한 자격 증명을 처리하는 데 사용되는 파일이 아닙니다. OAuth 클라이언트를 위한 서비스 계정을 생성할 때 두 번째 JSON 파일이 생성됩니다.

   예를 들면:

   

서비스 계정 만들기

서비스 계정을 만들려면:

1. Google Cloud 콘솔 사이드바에서 IAM 및 관리를 클릭한 다음 서비스 계정을 선택합니다.

2. 서비스 계정 만들기를 클릭합니다.

3. 서비스 계정의 이름을 입력하고, 선택적으로 서비스 계정의 목적에 대한 설명을 입력합니다.

4. 생성하고 계속을 클릭한 후 완료를 클릭합니다.

   

   완료를 클릭한 후 새 서비스 계정이 현재 프로젝트의 서비스 계정 목록에 추가됩니다. 새로 생성된 계정을 클릭하여 세부정보를 보고 계정에 대한 정보를 수정할 수 있습니다.

5. 새 서비스 계정을 클릭하여 세부정보를 표시하고 나중을 위해 고유 ID를 복사합니다.

   

6. 키를 클릭하고 키 추가를 클릭한 다음 새 키 만들기를 선택하여 서비스 계정을 위한 키를 생성합니다.

   

7. JSON을 키 유형으로 선택한 후 생성을 클릭합니다.

   Google Cloud는 다음과 유사한 서비스 계정의 키를 포함한 JSON 파일을 자동으로 다운로드합니다:

   {
      "type": "service_account",
      "project_id": "teleport-project-xxxxxx",
      "private_key_id": "f06e000000000000000dc18",
      "private_key": "-----BEGIN PRIVATE KEY-----\n0000000000000w==\n-----END PRIVATE KEY-----\n",
      "client_email": "g-w-sso@teleport-project-xxxxxx.iam.gserviceaccount.com",
      "client_id": "11xxxxxxxxxxxxx76",
      "auth_uri": "https://accounts.google.com/o/oauth2/auth",
      "token_uri": "https://oauth2.googleapis.com/token",
      "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
      "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/gwsso%40teleport-project-xxxxxx.iam.gserviceaccount.com",
      "universe_domain": "googleapis.com"
    }
   

   이 파일은 텔레포트 인증 서비스에서 사용할 OIDC 커넥터를 설정하는 데 사용됩니다. 호스트에서 로컬 파일을 참조하거나 커넥터 리소스를 생성하기 위해 커맨드라인에 내용을 포함합니다.

도메인 전체 위임 구성하기

이제 텔레포트에서 사용할 서비스 계정을 생성했으므로, 도메인 전체 위임 구성할 수 있습니다.

위임을 구성하려면:

1. Google Workspace 관리 콘솔을 열고 도메인 전체 위임 관리로 이동합니다.

2. 새로 추가를 클릭합니다.

3. 서비스 계정에서 복사한 숫자 고유 ID를 붙여넣습니다.

4. Google Workspace 에디션에 따라 다음 범위 중 하나를 추가합니다:

   • 직접 그룹만의 경우, 추가합니다: https://www.googleapis.com/auth/admin.directory.group.readonly
   • 직접 및 전이 그룹 구성원 자격 지원의 경우, 추가합니다: https://www.googleapis.com/auth/cloud-identity.groups.readonly

5. 승인을 클릭합니다.

2단계/4. OIDC 커넥터 만들기

Google Workspace를 준비한 후, tctl sso configure oidc 명령어를 실행하여 OIDC 커넥터를 만들 수 있습니다. 텔레포트 클러스터를 배포한 방법에 따라 OIDC 커넥터 리소스를 두 가지 방법 중 하나로 만들 수 있습니다:

• 커넥터 리소스를 생성하는 데 JSON을 내장하여 임베드할 수 있습니다.
• 텔레포트 인증 서비스를 실행하는 호스트에 서비스 계정 JSON 파일을 업로드할 수 있습니다.

JSON 파일은 텔레포트를 고가용성 클러스터로 배포하는 경우 모든 텔레포트 인증 서비스 호스트에서 사용 가능해야 합니다. 대부분의 경우, 여러 서버에 자격 증명을 파일로 저장하는 것을 피하기 위해 내장 JSON 방법을 사용하는 것이 좋습니다.

내장 JSON으로 OIDC 커넥터를 생성하는 대안은 JSON 파일을 업로드하는 것입니다. 자체 호스팅된 텔레포트 클러스터가 있는 경우, 텔레포트 인증 서비스를 실행하는 모든 호스트에 서비스 계정 JSON 파일을 업로드할 수 있습니다.

작업 스테이션에서 client-secret.txt라는 이름의 파일을 생성하여 클라이언트 비밀 정보만 포함합니다.

tctl sso configure oidc --preset google --id <CLIENT-ID> \--secret $( cat client-secret.txt) \--claims-to-roles groups,auditor@example.com,auditor \--claims-to-roles groups,teleport-developers@example.com,access \--google-admin=<GOOGLE-WORKSPACE-ADMIN-EMAIL> \--google-acc '
{  "type": "service_account",  "project_id": <GOOGLE-PROJECT-ID>,  "private_key_id": <GOOGLE-PRIVATE-KEY-ID>,  "private_key": "-----BEGIN PRIVATE KEY-----\n0000000000000w==\n-----END PRIVATE KEY-----\n",  "client_email": <GOOGLE-SERVICE-ACCOUNT-EMAIL>,  "client_id": <GOOGLE-SERVICE-ACCOUNT-UNIQUE-ID>,  "auth_uri": "https://accounts.google.com/o/oauth2/auth",  "token_uri": "https://oauth2.googleapis.com/token",  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/gwsso%40teleport-project-xxxxxx.iam.gserviceaccount.com",  "universe_domain": "googleapis.com"}'

kind: oidc
metadata:
  name: google
spec:
  claims_to_roles:
  - claim: groups
    roles:
    - auditor
    value: auditor@example.com
  - claim: groups
    roles:
    - access
    value: teleport-developers@example.com
  client_id: <CLIENT-ID>
  client_secret: <CLIENT-SECRET>
  display: Google
  google_admin_email: <GOOGLE-WORKSPACE-ADMIN-EMAIL>
  google_service_account: |2-

    {
      "type": "service_account",
      "project_id": <GOOGLE-CLOUD-PROJECT-ID>,
      "private_key_id": <GOOGLE-SERVICE-ACCOUNT-PRIVATE-KEY-ID>,
      "private_key": "-----BEGIN PRIVATE KEY-----\n0000000000000w==\n-----END PRIVATE KEY-----\n",
      "client_email": <GOOGLE-SERVICE-ACCOUNT-EMAIL>,
      "client_id": <GOOGLE-SERVICE-ACCOUNT-UNIQUE-ID>,
      "auth_uri": "https://accounts.google.com/o/oauth2/auth",
      "token_uri": "https://oauth2.googleapis.com/token",
      "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
      "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/gwsso%40teleport-project-xxxxxx.iam.gserviceaccount.com",
      "universe_domain": "googleapis.com"
    }
  issuer_url: https://accounts.google.com
  redirect_url: https://example.teleport.sh:443/v1/webapi/oidc/callback
version: v3

tctl sso configure oidc --preset google --id <CLIENT-ID> \--secret $( cat client-secret.txt) \--google-acc-uri <PATH/TO/SERVICE-ACCOUNT-KEY>.json \--claims-to-roles groups,auditor@example.com,auditor \--claims-to-roles groups,teleport-developers@example.com,access \--google-admin=<GOOGLE-WORKSPACE-ADMIN-EMAIL> > gworkspace-connector.yaml

kind: oidc
metadata:
  name: google
spec:
  claims_to_roles:
  - claim: groups
    roles:
    - auditor
    value: auditor@example.com
  - claim: groups
    roles:
    - access
    value: teleport-developers@example.com
  client_id: <CLIENT-ID>
  client_secret: <CLIENT-SECRET>
  display: Google
  google_admin_email: <GOOGLE-WORKSPACE-ADMIN-EMAIL>
  google_service_account_uri: </PATH-TO-SERVICE-ACCOUNT-KEY>.json
  issuer_url: https://accounts.google.com
  redirect_url: https://teleport.example.com/v1/webapi/oidc/callback
version: v3

google_admin_email에 설정한 이메일은 Google Workspace 내의 모든 그룹, 사용자 및 그룹 구성원 목록을 나열할 수 있는 권한이 있는 계정의 이메일 주소여야 합니다. 일반적으로 이 사용자 계정은 전체 관리 권한이나 그룹 관리 권한을 가져야 합니다.

google_admin_email에 서비스 계정의 이메일을 사용하지 마십시오. 설정이 동일하게 보일 수 있지만 서비스 계정은 필요한 도메인 전체 위임 권한이 없습니다.

client_id 필드는 Google Cloud 콘솔에서 OAuth 클라이언트를 위한 서비스 계정에 대해 생성된 고유 숫자 ID여야 합니다. 텔레포트 인증 서비스를 실행하는 호스트에서 감사 로그를 조회하거나 텔레포트 웹 UI의 관리 탭에서 이 설정이 올바르게 구성되었는지 확인할 수 있습니다. 감사 로그 메시지에서 "invalid Google Workspace credentials for scopes [...]"라는 메시지를 확인하면 리소스 구성 파일의 client_id 설정을 변경해야 합니다. 감사 로그 조회에 대한 자세한 내용은 문제 해결을 참조하세요.

커넥터를 테스트하려면 다음 명령어를 실행합니다:

cat gworkspace-connector.yaml | tctl sso test

이 명령은 브라우저를 열고 Google을 사용하여 텔레포트 클러스터에 로그인하려고 시도합니다. 실패할 경우, 명령 출력에서 문제 해결 정보를 검토합니다.

tctl 도구를 사용하여 커넥터를 생성하려면 다음 명령어를 실행합니다:

tctl create -f gworkspace-connector.yaml

3단계/4. Google Workspace OIDC 커넥터 테스트

커넥터를 생성한 후, 텔레포트 웹 UI에 Google로 로그인이라는 새로운 로그인 옵션이 표시됩니다. 명령줄에서 로그인하려면:

tsh --proxy=proxy.example.com login --auth=google

이 명령은 단일 로그인 엔드포인트 URL을 표시하고 자동으로 브라우저에서 열려고 시도합니다.

4단계/4. 기본 OIDC 인증 활성화하기

OIDC 인증을 기본으로 사용하도록 Teleport를 구성하고 로컬 사용자 데이터베이스 대신 사용하십시오.

귀하의 Teleport 에디션에 대한 지침을 따르십시오:

auth_service:
  authentication:
    type: oidc

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:    
  type: oidc
version: v2

tctl create -f cap.yaml

문제 해결

SSO 구성 문제를 해결하는 것은 어려울 수 있습니다. 일반적으로 Teleport 관리자는 다음을 수행할 수 있어야 합니다:

• SSO 공급자가 Teleport에 내보내고 전달하는 SAML/OIDC 클레임 및 값이 무엇인지 확인할 수 있어야 합니다.
• 관련 클레임을 커넥터에서 정의된 역할 매핑으로 Teleport가 어떻게 매핑하는지 확인할 수 있어야 합니다.
• 자체 호스팅된 Teleport Enterprise 클러스터의 경우, Teleport 프록시 서비스와 SSO 공급자 모두에 대해 HTTP/TLS 인증서가 올바르게 구성되어 있는지 확인해야 합니다.

무언가가 작동하지 않는 경우, 다음을 권장합니다:

• 커넥터 정의에서 호스트 이름, 토큰 및 TCP 포트를 다시 확인하십시오.

웹 UI 사용하기

"액세스가 거부되었습니다." 또는 다른 로그인이 오류가 발생하면 가장 먼저 확인해야 할 곳은 감사 로그입니다. 관리 영역 아래에서 Teleport 웹 UI의 활동 탭 내에서 액세스할 수 있습니다.

역할 clusteradmin이 설정되지 않아 사용자가 거부된 예:

{  
  "code": "T1001W",  
  "error": "role clusteradmin is not found",  
  "event": "user.login",  
  "method": "oidc",  
  "success": false,  
  "time": "2019-06-15T19:38:07Z",  
  "uid": "cd9e45d0-b68c-43c3-87cf-73c4e0ec37e9"  
}  

Teleport가 예상하는 노드를 표시하지 않음

When Teleport의 인증 서비스가 Teleport 노드를 나열하라는 요청을 받으면 (예: 웹 UI에서 노드를 표시하거나 tsh ls를 통해), 현재 사용자가 볼 수 있는 권한이 있는 노드만 반환합니다.

사용자의 Teleport 클러스터에 있는 각 노드에 대해 인증 서비스는 다음 검사를 순서대로 적용하며, 하나의 검사가 실패하면 해당 노드를 사용자에게 숨깁니다:

• 사용자의 역할 중 어느 것도 노드의 레이블과 일치하는 deny 규칙을 포함하지 않아야 합니다.
• 사용자의 역할 중 적어도 하나는 노드의 레이블과 일치하는 allow 규칙을 포함해야 합니다.

예상할 때 노드를 볼 수 없다면, 사용자의 역할에 Teleport 접근 제어 참조에 문서화된 적절한 allow 및 deny 규칙이 포함되어 있는지 확인하세요.

SSO를 구성할 때, 각 사용자의 특성이 올바르게 채워지고 있는지 확인하십시오. 사용자가 Teleport에서 노드를 보려면 역할의 allow.logins에서 템플릿 변수를 채우는 결과가 사용자의 traits.logins 중 하나와 일치해야 합니다.

이 예에서 사용자는 env: dev 레이블이 있는 노드에 대해 ubuntu, debian 및 SSO 특성 logins에서 가져온 사용자 이름을 가집니다. SSO 특성 사용자 이름이 bob인 경우 사용자 이름에는 ubuntu, debian 및 bob이 포함됩니다.

kind: role  
metadata:  
  name: example-role  
spec:  
  allow:  
    logins: ['{{external.logins}}', ubuntu, debian]  
    node_labels:  
      'env': 'dev'  
version: v5  

OIDC로 단일 로그인 실패

"JWT 확인 실패: oidc: JWT 서명을 검증할 수 없음: 일치하는 키가 없음"이라는 오류 메시지를 받으면, 일반적으로 JWT 토큰 서명에 사용된 알고리즘과 JSON 웹 키 세트(JWKS)에서 지원되는 알고리즘 간의 불일치를 나타냅니다. 특히, 토큰이 한 알고리즘, 예를 들어 HS256으로 서명된 경우, JWKS는 다른 알고리즘에 대한 키만 나열할 수 있습니다. 예를 들어 RS256. 이 문제는 기본 기능을 제공하는 ID 공급자를 사용할 때 주로 발생합니다.

확인해야 할 사항은 다음과 같습니다:

• JWT 헤더가 올바른 서명 알고리즘을 지정하는지 확인하십시오. 이는 JWKS 엔드포인트 응답의 키 섹션에 나열된 알고리즘 중 하나와 일치해야 합니다.
• JWKS 엔드포인트가 모든 관련 공개 키를 반환하는지 확인하십시오. 때때로 키가 회전하면 유효한 키가 누락될 수 있습니다.

문제를 해결하려면 JWT 알고리즘 헤더를 JWKS에서 지원되는 알고리즘과 일치시킵니다. 필요한 경우 키를 회전시킵니다. JWKS가 활성 공개 키만 게시하는지 확인하십시오. 올바른 구성으로 서명이 성공적으로 검증되어야 합니다.

추가 읽기

• Google Workspace Cloud Identity API
• Google Workspace Directory API
• 중첩된 Google Workspace 그룹 작동 방식