Infograb logo
Okta 및 SCIM과의 동기화

Okta 통합은 Okta 조직의 리소스를 가져오고 동기화합니다. 이 가이드는 이러한 Okta 리소스가 Teleport 클러스터 내에서 어떻게 표현되는지를 자세히 설명합니다.

동기화 및 SCIM

Teleport는 Teleport 리소스를 상위 Okta 조직과 동기화하기 위해 두 가지 보완적인 방법을 사용합니다:

  • Okta 통합 동기화 프로세스
  • SCIM을 통한 프로비저닝

전반적으로, 어떤 방법을 사용하여 사용자를 가져왔는지는 더 넓은 Teleport 시스템에 중요하지 않습니다. 두 프로세스 모두 Teleport 내에서 동일한 리소스를 생성합니다.

사용자 프로비저닝을 보완하기 위해, Okta는 또한 Okta 권한을 Access Lists로 모델링할 수 있습니다. 이는 Okta의 애플리케이션 권한을 효과적으로 Teleport로 가져옵니다.

사용자

사용자 가져오기

동기화 동안 Okta 통합은 모든 유자격 Okta 사용자에 대해 Teleport 사용자 계정을 생성하고 비활성화된 Okta 사용자의 Teleport 계정을 정리합니다. "유자격 Okta 사용자" 목록은 통합 구성에 따라 다릅니다.

Okta 통합이 특정 Okta 애플리케이션을 사용하도록 구성된 경우, Okta 통합은 해당 Okta 애플리케이션에 직접적으로 또는 그룹 회원 자격을 통해 할당된 모든 Okta 사용자를 "유자격 사용자"로 간주합니다.

사용할 Okta 애플리케이션이 제공되지 않으면 모든 활성화된 Okta 조직 사용자가 "유자격"으로 간주됩니다.

Note

모든 호스팅된 Okta 통합은 특정 Okta 애플리케이션에 사용자 풀이 제한되도록 구성되어 있습니다.

통합 등록 프로세스는 새로운 SAML 인증 커넥터를 위한 아이덴티티 공급자로 사용할 Okta SAML 애플리케이션을 생성합니다. 등록 프로세스는 이 동일한 애플리케이션을 사용하도록 Okta 통합을 자동으로 구성하여 Okta 관리자가 관리하고 보호할 수 있는 단일 통합 지점을 제공합니다.

Okta 프로필에서 Teleport 사용자로

동기화 프로세스 또는 SCIM 프로비저닝에 의해 생성된 Teleport 사용자는 모두 상위 Okta 조직에서 사용자 이름을 상속받으며, 기본 역할인 okta-requester가 부여됩니다.

이 역할은 사용자가 Teleport에 로그인할 수 있도록 허용하지만, Teleport 리소스에 대한 기본 접근은 부여하지 않습니다. Teleport 관리자는 Access Requests 및 Access Lists를 사용하여 사용자가 가져온 후 적합하다고 생각되는 Teleport 리소스에 접근 권한을 부여할 수 있습니다.

특성

Okta 사용자/AppUser 프로필의 모든 비어 있지 않은 값은 Teleport 사용자 특성으로 변환됩니다. 예를 들어, 가져온 Okta 사용자는 다음과 같을 수 있습니다:

kind: user
metadata:
  name: hiro@enzos-pizza.com
  labels:
    okta/org: https://enzos-pizza.okta.com
    teleport.dev/origin: okta
roles:
  - okta-requester
spec:
  traits:
    okta/email:
      - hiro@enzos-pizza.com
    okta/firstName:
      - Hiro
    okta/lastName:
      - Protagonist
    okta/login:
      - hiro@enzos-pizza.com

Teleport 관리자들은 이러한 특성을 Access Lists의 조건으로 사용하여 Okta에서 파생된 Teleport 사용자에게 Teleport 리소스에 대한 접근을 부여하거나 거부할 수 있습니다.

사용자 삭제

동기화 프로세스가 Okta 사용자가 비활성화되거나 정지된 경우를 감지하거나, Okta 조직이 SCIM을 통해 계정을 명시적으로 비활성화하는 경우에는,

Okta 통합은 해당 Teleport 계정을 즉시 삭제하고 임시 Teleport 사용자 잠금을 생성합니다. 사용자 잠금은

  • 모든 활성 Teleport 세션을 종료하고,
  • 비활성화된 사용자가 Teleport 계정이 삭제되기 전에 발급된 자격 증명으로 Teleport 리소스에 접근하는 것을 방지합니다.

사용자 잠금은 최대 자격 증명 수명 후, 약간의 안전 마진과 함께 만료됩니다.

Warning

정지된 Okta 사용자는 Teleport에 의해 잠금되지 않습니다.

사용자가 Okta에서 정지되면 Okta는 정지 사실을 Teleport에 통신하지 않으며, 따라서 Teleport는 해당 사용자를 자동으로 잠그고 삭제하지 않습니다.

사용자의 상태를 Teleport에서 업데이트하려면 사용자를 비활성화하거나 Okta SAML 애플리케이션에서 사용자 할당을 해제해야 합니다.

Access Lists

Teleport 내에서 Okta 권한 모델링

Okta는 Teleport와 잘 매핑되지 않는 자체 권한 시스템을 가지고 있습니다. 여기에는 Okta 그룹에 의해 부여된 권한과 Okta 내 개별 애플리케이션에 사용자 할당이 포함됩니다. 이는 Teleport 내에서 모델링하기 위해 관리자가 일반적으로 다양한 Okta 앱 및 그룹에 부착할 레이블 시스템과 함께 사용할 역할 집합을 신중하게 제작해야 함을 의미합니다.

새로운 Access List 동기화 기능을 사용하면 이 작업이 자동으로 수행됩니다. 이 기능이 어떻게 작동하는지에 대해 논의하겠습니다.

Okta 그룹 및 애플리케이션에서 액세스 목록 동기화

Okta Access List 동기화기는 구성 가능한 필터와 일치하는 모든 Okta 그룹의 구성원이나 개별 할당이 있는 Okta 애플리케이션을 찾습니다. 할당이 없는 그룹이나 애플리케이션에 대해서는 Access Lists가 생성되지 않습니다.

동기화기는 매칭되는 각 그룹 또는 애플리케이션에 대해 다음과 같은 리소스를 생성합니다:

  • 그룹/애플리케이션에 대한 액세스를 부여하는 구성원을 위한 역할.
  • 그룹/애플리케이션에 대한 액세스를 검토할 수 있는 소유자를 위한 역할.
  • 그룹/애플리케이션에 대한 구성원 자격을 나타내는 Access List.
  • Access List의 구성원.

Access List 동기화는 Okta 그룹과 Okta 애플리케이션이 Teleport 리소스와 동기화가 완료될 때까지 기다리며, 따라서 시작 시에 즉시 동기화를 시작하지 않을 수 있습니다.

Access Lists 삭제

Okta에서 동기화된 Access Lists는 Okta에서 할당된 사용자가 없거나 Okta에서 삭제될 경우 자동으로 삭제됩니다.

Warning

관리자가 Access Lists를 삭제할 수 있지만, 이는 Okta 통합이 제거되고 Access List 동기화가 비활성화된 후에만 수행해야 합니다. 이는 대상이 되는 Okta 그룹이나 애플리케이션에서 모든 사용자가 제거될 수 있습니다!

동기화된 Access Lists 작업하기

Access List를 처음 동기화할 때, Access List의 소유자는 초기 Okta 통합 등록 동안 구성된 기본 소유자로 설정되며, 초기 검토 날짜는 구성된 날짜로부터 6개월로 설정됩니다. 이러한 필드는 수정 가능하며, 소유자 및 구성원 요구 사항도 변경할 수 있습니다. 그러나 부여는 변경할 수 없으며, 이는 Okta Access List 동기화기에 속합니다.

Okta에서 동기화된 Access List의 소유자는 실행 간에 유지됩니다.

Warning

Okta에서 동기화된 Access List의 구성원에서 사용자를 제거하면 사용자가 Okta 그룹이나 Okta 애플리케이션에서 제거됩니다. 이는 사용자가 할당에 의해 전달되는 다른 할당이 없을 경우에 해당합니다. 이 방식으로 Teleport는 Okta 회원 자격의 진실의 출처가 됩니다. 추가 자동화 워크플로우나 통합을 Okta 환경에 추가할 때 이 점을 유의하시기 바랍니다.

Teleport 원문 보기