Google Workspace (G Suite) 를 통한 Teleport 인증

이 가이드는 Google Workspace 를 특정 사용자 그룹에 Teleport 자격 증명을 발급하는 단일 사인온(SSO) 공급자로 구성하는 방법에 대해 설명합니다. Google Workspace를 Teleport의 역할 기반 접근 제어(RBAC)와 조합하여 사용할 경우, 다음과 같은 정책을 정의할 수 있습니다:

"DBA" Google 그룹의 회원만 PostgreSQL 데이터베이스에 연결할 수 있습니다.
개발자는 운영 서버에 SSH를 사용하여 접근해서는 안 됩니다.

사전 요구 사항

시작하기 전에 다음 사항을 확인하십시오:

Google Workspace 슈퍼 관리 계정이 있어야 합니다. 모범 사례로, 관리 작업을 수행하기 위해 다중 인증이 필요한 별도의 계정을 설정해야 합니다. 대부분의 경우, 자신의 로그인 사용자 계정에 높은 관리 권한을 부여하지 않아야 합니다.
Google Cloud에 가입하고 Google Cloud 프로젝트를 생성할 수 있어야 합니다. 이 가이드는 유료 Google Cloud 서비스를 사용할 필요가 없습니다.
Google Workspace 그룹을 설정할 수 있어야 합니다.
oidc 리소스를 유지 관리할 수 있는 권한을 가진 Teleport 역할이 있어야 합니다. 이 권한은 미리 설정된 editor 역할에서 사용할 수 있습니다.
Teleport 클러스터, 엔터프라이즈 에디션 및 명령줄 도구가 있어야 합니다.
- 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하여 무료 평가판을 이용해 보십시오.
- tctl 관리자 도구 및 tsh 클라이언트 도구.
  
  tctl 및 tsh 다운로드에 대한 지침은 설치 를 방문하십시오.
연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오.

예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  17.0.0-dev
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1/4 단계. Google Workspace 구성

Google Workspace가 Teleport와 함께 작동하도록 구성하려면 다음 단계가 필요합니다:

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

Google Workspace 에디션 검토

Google Workspace는 개인 및 조직을 위해 다양한 기능과 능력을 가진 여러 에디션으로 제공됩니다. Google Workspace 에디션 간의 차이로 인해, 사용하는 Google Workspace 에디션에 따라 Teleport와 Google Workspace 간의 통합 방법에서 근본적인 차이가 있습니다.

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

Google Workspace 에디션 및 API

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

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

Teleport가 Google Workspace API를 사용하는 방법

Teleport OIDC 커넥터는 Google Workspace API를 사용하여 Google Workspace 그룹 구성원을 그들이 속한 Teleport 역할로 매핑합니다.

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

자격 증명이 존재하지 않으면 Teleport는 Directory API 메서드를 호출하여 자격 증명을 얻습니다. 그런 다음 Teleport는 Directory API를 사용하여 사용자의 그룹을 Google Workspace 전체에서 나열합니다. 사용자가 속한 외부 그룹은 나열되지 않습니다.

현재 에디션 확인 방법

Google Workspace 에디션이 전이 그룹 멤버십 쿼리를 지원하는지 확인하려면:

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

그룹 검사는 Cloud Identity API에 의존합니다.
구성원의 모든 그룹 나열 및 외부 그룹 포함을 선택합니다.

Google Workspace 에디션이 Cloud Identity API를 지원하는 경우, 외부 그룹에 대한 접근 허용 또는 차단에서 설명한 대로 작업 공간 수준에서 외부 그룹에 대한 접근을 차단해야 합니다. 그렇지 않으면 작업 공간 외부의 모든 그룹 멤버십은 사용자의 로그인을 방해합니다.

Google Workspace 에디션이 Cloud Identity API를 지원하지 않는 경우, 역할 기반 접근 제어가 전이 그룹 멤버십에 의존하지 않도록 해야 합니다.

새 프로젝트 만들기

기존 Google Cloud 프로젝트에 Teleport의 단일 로그인 기능을 추가하려는 경우, Google Cloud 콘솔에서 해당 프로젝트를 선택하고 이 단계를 건너뛸 수 있습니다. 프로젝트가 없거나 Teleport 전용으로 새 프로젝트를 만들고 싶다면, 활성화된 API 및 서비스 프로젝트 선택기 대시보드로 바로 가서 프로젝트를 만들 수 있습니다.

새 프로젝트를 만들려면:

Google Cloud 콘솔을 엽니다.
Google Cloud 콘솔 탐색 메뉴에서 API 및 서비스를 클릭합니다.
활성화된 API 및 서비스에서 프로젝트 선택기를 클릭한 다음 새 프로젝트를 클릭합니다. 대시보드에서 선택할 프로젝트가 없는 경우 프로젝트 만들기를 클릭합니다.
프로젝트 이름을 입력하고 프로젝트에 대한 조직 및 위치를 선택한 다음 생성을 클릭합니다.

OAuth 동의 구성

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

Google Cloud 콘솔 사이드바에서 OAuth 동의 화면을 클릭합니다.
사용자 유형으로 내부를 선택한 다음 생성을 클릭합니다.
다음과 같이 OAuth 클라이언트 동의 정보를 구성합니다:
- 애플리케이션 이름을 입력합니다.
- OAuth 동의에 대한 이메일 메시지를 받을 사용자 또는 그룹을 선택합니다.
- 필요한 경우 다른 애플리케이션 옵션을 설정합니다.
- 프로젝트에 변경이 있을 경우 연락할 개발자의 이메일 주소를 제공합니다.
저장하고 계속 클릭합니다.
범위 추가 또는 제거 클릭합니다.
.../auth/userinfo.email 및 openid 범위를 선택한 다음 업데이트를 클릭합니다.
저장하고 계속 클릭합니다.
요약 페이지의 정보를 검토한 다음 대시보드로 돌아가기 클릭합니다.

필요한 API 활성화

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

API 라이브러리에서 Admin SDK API 를 선택한 다음 활성화를 클릭하여 직접 그룹 멤버십을 지원합니다.
API 라이브러리에서 Cloud Identity API 를 선택한 다음 활성화를 클릭하여 전이 그룹 멤버십을 지원합니다.

하나 또는 두 개의 API 라이브러리를 활성화할 수 있습니다.
그러나 선택한 API를 사용하려면 Google Workspace 에디션이 이를 지원해야 합니다.
사용하려는 API 라이브러리에 대한 문서를 참조하여 지원되는 Google Workspace 에디션이 있는지 확인하십시오.

OAuth 클라이언트 ID 생성

OAuth 클라이언트 식별자를 생성하려면:

Google Cloud 콘솔 사이드바에서 APIs & Services를 클릭합니다.
APIs & Services 사이드바에서 Credentials를 클릭합니다.
Create credentials를 클릭하여 생성할 수 있는 자격 증명의 목록을 표시합니다.
OAuth client ID를 선택합니다.
애플리케이션 유형으로 Web application을 선택하고 애플리케이션의 이름을 입력합니다.
승인된 리디렉션 URI 아래에서 Add URI를 클릭합니다.
리디렉션 URI를 Teleport 클러스터의 주소로 설정한 다음 URI에 /v1/webapi/oidc/callback 을 추가합니다.
Create를 클릭합니다.
생성된 OAuth 클라이언트에서 Client ID 및 Client secret을 복사하거나 Download JSON을 클릭하여 이 정보를 저장한 후 OK를 클릭합니다.

클라이언트 식별자와 클라이언트 비밀을 Download JSON 클릭하여 저장하기로 선택한 경우, 이 JSON 파일은 인증을 위한 자격 증명을 처리하는 데 사용되는 파일이 아님을 유의해야 합니다. OAuth 클라이언트에 대한 서비스 계정을 생성하면 두 번째 JSON 파일이 생성됩니다.

예를 들어:

서비스 계정 생성

서비스 계정을 생성하려면:

Google Cloud 콘솔 사이드바에서 IAM & admin을 클릭한 다음 Service Accounts를 선택합니다.
Create service account를 클릭합니다.
서비스 계정의 이름을 입력하고, 선택적으로 서비스 계정의 용도에 대한 설명을 입력합니다.
Create and continue를 클릭한 다음 Done을 클릭합니다.

Done을 클릭한 후, 새로운 서비스 계정이 현재 프로젝트의 서비스 계정 목록에 추가됩니다. 새로 생성된 계정을 클릭하여 상세 정보를 보고 계정 정보를 편집할 수 있습니다.
새 서비스 계정을 클릭하여 세부 정보를 표시하고, 나중에 사용할 Unique ID를 복사합니다.
Keys를 클릭하고 Add key를 클릭한 다음 Create new key를 선택하여 서비스 계정의 키를 생성합니다.

키 유형으로 JSON을 선택한 후 Create를 클릭합니다.

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",
}

이 파일은 Teleport Auth Service가 사용할 OIDC 커넥터를 구성하는 데 사용되며, Teleport Auth Service가 실행되고 있는 호스트의 로컬 파일을 참조하거나 커넥터 리소스를 만들기 위해 명령 줄에 내용을 포함하는 방식으로 사용할 수 있습니다.

도메인 전체 위임 구성

Teleport에서 사용할 서비스 계정을 만들었으므로, 도메인 전체 위임을 서비스 계정에 대해 구성할 수 있습니다.

위임 구성 방법:

Google Workspace 관리자 콘솔을 열고 도메인 전체 위임 관리로 이동합니다.
새로 추가를 클릭합니다.
서비스 계정에서 복사한 숫자 고유 ID를 붙여넣습니다.
Google Workspace 에디션에 따라 다음 중 하나의 범위를 추가합니다:
- 직접 그룹만을 위해 추가: https://www.googleapis.com/auth/admin.directory.group.readonly
- 직접 및 전이 그룹 구성원 지원을 위해 추가: https://www.googleapis.com/auth/cloud-identity.groups.readonly
허가를 클릭합니다.

2/4단계. OIDC 커넥터 생성

Google Workspace를 준비한 후, tctl sso configure oidc 명령을 실행하여 OIDC 커넥터를 생성할 수 있습니다. Teleport 클러스터를 배포한 방법에 따라 OIDC 커넥터 자원을 두 가지 방법 중 하나로 생성할 수 있습니다:

커넥터 자원에 서비스 계정 정보를 내장할 수 있습니다.
Teleport Auth Service를 실행하는 호스트에 서비스 계정 JSON 파일을 업로드할 수 있습니다.

Teleport를 고가용성 클러스터로 배포하는 경우 모든 Teleport Auth Service 호스트에서 서비스 계정 JSON을 사용할 수 있어야 합니다. 대부분의 경우, 여러 서버에 자격 증명을 파일로 저장하는 것을 피하기 위해 고가용성 및 클라우드 배포에서 내장 JSON 방법을 사용하는 것이 좋습니다.

내장 JSON으로 OIDC 커넥터를 생성하는 대신 JSON 파일을 업로드할 수 있습니다. 자체 호스팅된 Teleport 클러스터가 있는 경우, Teleport Auth Service를 실행하는 모든 호스트에 서비스 계정 JSON 파일을 업로드할 수 있습니다.

워크스테이션에서 client-secret.txt 라는 파일을 생성하고, 클라이언트 비밀만 포함하세요.

다음 명령은 커넥터 자원을 생성하는 데 사용되는 명령에 JSON을 내장하여 서비스 계정을 정의합니다. 이 방법을 사용하면 Teleport Auth Service를 실행하는 모든 호스트에 JSON 파일을 제공할 필요가 없습니다.

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"}'

이 명령을 복사한 후, 괄호(< >)를 제거하고 Google Workspace에 적합한 정보로 자리 표시자 문자열을 교체하세요. 예를 들어, <GOOGLE-WORKSPACE-ADMIN-EMAIL>을 admin@yourdomain.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

다음 명령은 Teleport Auth Service를 실행하는 호스트에서 JSON 파일의 경로를 지정합니다. 이 방법은 Teleport Auth Service 인스턴스를 자체 호스팅하는 경우 모든 호스트에서 JSON 파일을 사용할 수 있는 경우에 사용할 수 있습니다.

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여야 합니다. 이 설정이 올바르게 구성되었는지 확인하려면 Teleport Auth Service를 실행하는 호스트에서 감사 로그를 보거나 Teleport 웹 UI의 관리 탭에서 확인할 수 있습니다. 감사 로그 메시지에서 "invalid Google Workspace credentials for scopes [...]"를 확인하면 리소스 구성 파일에서 client_id 설정을 변경하십시오. 감사 로그 보기의 자세한 내용은 문제 해결을 참조하십시오.

커넥터를 테스트하려면 다음 명령을 실행하십시오:

cat gworkspace-connector.yaml | tctl sso test

이 명령은 브라우저를 열고 Google을 사용하여 Teleport 클러스터에 로그인하려고 시도합니다. 실패하면 문제 해결 정보를 위해 명령 출력을 검토하십시오.

tctl 도구를 사용하여 커넥터를 생성하려면 다음 명령을 실행하십시오:

tctl create -f gworkspace-connector.yaml

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

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

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

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

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

Teleport를 로컬 사용자 데이터베이스 대신 OIDC 인증을 기본값으로 사용하도록 구성합니다.

cluster_auth_preference 리소스를 편집합니다:

tctl edit cap

편집기에서 파일에 다음 내용이 포함되어 있는지 확인합니다:

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

문제 해결

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",
  "message": "Failed to calculate user attributes.\n\trole clusteradmin is not found",
  "method": "oidc",
  "success": false,
  "time": "2024-11-07T15:41:25.584Z",
  "uid": "71e46f17-d611-48bb-bf5e-effd90016c13"
}

Teleport에서 예상되는 노드가 표시되지 않음

Teleport의 Auth 서비스가 Teleport 노드를 목록화하라는 요청을 받을 때(예: 웹 UI에서 노드를 표시하거나 tsh ls 를 통해), 현재 사용자가 볼 수 있는 노드만 반환합니다.

사용자의 Teleport 클러스터의 각 노드에 대해 Auth 서비스는 다음과 같은 검사를 순서대로 적용하며, 하나의 검사가 실패할 경우 해당 노드를 사용자에게 숨깁니다:

사용자의 역할 중 어느 것도 노드의 레이블과 일치하는 deny 규칙을 포함하지 않습니다.
사용자의 역할 중 최소 하나가 노드의 레이블과 일치하는 allow 규칙을 포함합니다.

예상치 못하게 노드가 보이지 않는 경우, 사용자의 역할에 적절한 allow 및 deny 규칙이 포함되어 있는지 확인하십시오. 이는 Teleport Access Controls Reference에서 문서화되어 있습니다.

SSO를 구성할 때, ID 공급자가 각 사용자의 특성을 올바르게 인구시키고 있는지 확인하십시오. 사용자가 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가 활성 공개 키만 게시하는지 확인하십시오. 올바른 구성이 이루어지면 서명이 성공적으로 검증되어야 합니다.

추가 자료

Teleport 원문 보기