Teleport는 Proxy 서비스 또는 authentication connectors를 통해 사용자 인증을 수행합니다.
로컬 (인증 커넥터 없음)
로컬 인증은 로컬 Teleport 사용자 데이터베이스에 대해 인증하는 데 사용됩니다. 이 데이터베이스는 tctl users
명령어로 관리됩니다. Teleport는 로컬 커넥터에 대해 다단계 인증(MFA)도 지원합니다. MFA의 여러 가능한 값(유형)이 있습니다:
otp
는 기본값입니다. TOTP 표준을 구현합니다. Google Authenticator, Authy 또는 기타 TOTP 클라이언트를 사용할 수 있습니다.webauthn
은 두 번째 인증기를 사용하고 하드웨어 장치를 이용하기 위한 Web Authentication 표준을 구현합니다. YubiKeys, SoloKeys 또는 FIDO2 또는 FIDO U2F 표준을 구현하는 모든 인증기를 사용할 수 있습니다. Teleport에 대한 WebAuthn 설정에 대한 자세한 지침은 Second Factor - WebAuthn 가이드를 참조하세요.on
은 TOTP와 WebAuthn을 모두 활성화하며, 모든 로컬 사용자는 최소 한 개의 MFA 장치가 등록되어 있어야 합니다.optional
은 TOTP와 WebAuthn을 모두 활성화하되, 사용자에게 선택 사항으로 만듭니다. MFA 장치를 등록한 로컬 사용자는 로그인 시 MFA를 요청받습니다. 이 옵션은 MFA 사용을 점진적으로 활성화해야 할 때 유용합니다.off
는 다단계 인증을 비활성화합니다.
Teleport를 Single Sign-On 솔루션과 함께 사용하는 경우, 사용자는 MFA 장치를 등록할 수 있지만 로그인 시 Teleport는 MFA를 요청하지 않습니다. SSO 사용자에 대한 MFA는 SSO 공급자가 처리해야 합니다.
이 설정은 정적 구성 파일 또는 동적 구성 리소스를 사용하여 수정할 수 있습니다.
정적 구성
다음 내용을 Teleport 구성 파일, 기본적으로 /etc/teleport.yaml
에 저장합니다.
auth_service:
authentication:
type: local
second_factor: on
webauthn:
rp_id: example.teleport.sh
동적 리소스
기존의 cluster_auth_preference
리소스를 가져옵니다:
tctl get cap > cap.yaml
cap.yaml
에 다음 내용이 포함되어 있는지 확인하세요:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
type: local
second_factor: "on"
webauthn:
rp_id: example.teleport.sh
version: v2
tctl
를 통해 cluster_auth_preference
리소스를 생성합니다:
tctl create -f cap.yaml
이 설정은 동적 구성 리소스를 사용하여 수정할 수 있습니다.
로컬 머신에서 Teleport에 로그인하여 tctl
관리 도구를 사용할 수 있습니다:
tsh login --proxy=myinstance.teleport.shtctl status
기존의 cluster_auth_preference
리소스를 가져옵니다:
tctl get cap > cap.yaml
cap.yaml
에 다음 내용이 포함되어 있는지 확인하세요:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
type: local
second_factor: "on"
webauthn:
rp_id: example.teleport.sh
version: v2
tctl
를 통해 cluster_auth_preference
리소스를 생성합니다:
tctl create -f cap.yaml
로컬 사용자 정책
Teleport는 로컬 사용자의 비밀번호가 최소 12자여야 합니다.
또한, Teleport는 30분 이내에 여러 번 로그인 실패가 발생할 경우 로컬 사용자 계정을 잠급니다. 계정은 30분 동안 잠겨 있으며, 이후 사용자는 다시 로그인 시도를 할 수 있습니다.
블락 해제는 user
리소스를 유지관리할 권한이 있는 사용자에게 제공되며, 내장된 editor
역할에서 사용할 수 있습니다. 차단을 해제하려면 사용자 항목을 업데이트하세요.
상태를 편집할 수 있도록 사용자 항목을 가져옵니다:
tctl get users/username > user.yaml
user.yaml
파일은 다음과 유사해야 합니다:
kind: user
metadata:
name: jeff
spec:
roles:
- access
status:
is_locked: true
lock_expires: "2023-04-22T01:55:02.228158166Z"
locked_message: user has exceeded maximum failed login attempts
version: v2
status
아래의 is_locked
필드를 false
로 업데이트하고 파일을 저장합니다. 이제 아래 명령어로 사용자 항목을 업데이트합니다:
tctl create -f user.yaml
사용자는 이제 로그인 시도에서 차단 해제되며, 다시 인증을 시도할 수 있습니다.
인증 커넥터
GitHub
이 커넥터는 GitHub의 OAuth 2.0 인증 흐름을 구현합니다. OAuth 앱을 생성하고 등록하는 방법에 대해서는 GitHub의 Creating an OAuth App 문서를 참조하세요.
여기 cluster_auth_preference
리소스에서 이 설정의 예시가 있습니다:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
type: github
version: v2
구성 방법에 대한 세부 정보는 GitHub OAuth 2.0를 참조하세요.
SAML
이 커넥터 유형은 SAML 인증을 구현합니다. Okta 또는 Auth0와 같은 외부 ID 관리자에 대해 구성할 수 있습니다.
여기 cluster_auth_preference
리소스에서 이 설정의 예시가 있습니다:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
type: saml
version: v2
OIDC
Teleport는 OpenID Connect (OIDC) 인증을 구현합니다.
여기 cluster_auth_preference
리소스에서 이 설정의 예시가 있습니다:
kind: cluster_auth_preference
metadata:
name: cluster-auth-preference
spec:
type: oidc
version: v2
GitHub
이 커넥터는 GitHub의 OAuth 2.0 인증 흐름을 구현합니다. OAuth 앱을 생성하고 등록하는 방법에 대해서는 GitHub의 Creating an OAuth App 문서를 참조하세요.
여기 teleport.yaml
에서 이 설정의 예시가 있습니다:
auth_service:
authentication:
type: github
구성 방법에 대한 세부 정보는 GitHub OAuth 2.0를 참조하세요.
SAML
이 커넥터 유형은 SAML 인증을 구현합니다. Okta 또는 Auth0와 같은 외부 ID 관리자에 대해 구성할 수 있습니다.
여기 teleport.yaml
에서 이 설정의 예시가 있습니다:
auth_service:
authentication:
type: saml
OIDC
Teleport는 SAML과 원칙적으로 유사한 OpenID Connect (OIDC) 인증을 구현합니다.
여기 teleport.yaml
에서 이 설정의 예시가 있습니다:
auth_service:
authentication:
type: oidc
GitHub
이 커넥터는 GitHub의 OAuth 2.0 인증 흐름을 구현합니다. OAuth 앱을 생성하고 등록하는 방법에 대해서는 GitHub의 Creating an OAuth App 문서를 참조하세요.
여기 teleport.yaml
에서 이 설정의 예시가 있습니다:
auth_service:
authentication:
type: github
구성 방법에 대한 세부 정보는 GitHub OAuth 2.0를 참조하세요.