엔티티와 ID
엔티티와 ID (Identity)
이 문서는 Identity(신원) 에 대한 개념적 정보와 관련 용어·개념의 개요를 제공합니다. 엔티티와 ID의 아이디어는 Vault가 인식하는 클라이언트를 유지·관리하는 것입니다. Vault는 Identity 시크릿 엔진을 통해 신원 관리 솔루션을 제공합니다.
출처: 문서
본문
엔티티와 별칭 (Entities and aliases)
각 사용자는 다양한 신원 제공자에 여러 계정을 가질 수 있고, Vault는 그 중 많은 제공자를 인증에 지원합니다. Vault Identity는 다양한 인증 메서드의 인증을 단일 표현으로 묶을 수 있습니다. 이렇게 통합된 신원 표현을 엔티티(Entity) 라고 하고, 인증 제공자가 있는 해당 계정들은 별칭(Alias) 으로 매핑할 수 있습니다. 본질적으로 각 엔티티는 0개 이상의 별칭으로 구성됩니다. 엔티티는 특정 인증 백엔드에 대해 두 개 이상의 별칭을 가질 수 없습니다.
예를 들어 GitHub와 LDAP 양쪽에 계정이 있는 사용자는, GitHub 유형과 LDAP 유형의 두 별칭을 가진 단일 엔티티로 Vault에 매핑할 수 있습니다.
단, 두 별칭이 같은 인증 마운트(예: 같은 GitHub 마운트)에 생성되면 두 별칭을 같은 엔티티에 매핑할 수 없습니다. 별칭의 인증 유형이 같아도 인증 마운트가 다르면 같은 엔티티에 연결될 수 있습니다.
클라이언트가 어떤 자격 증명 백엔드(Token 백엔드 제외)로 인증하면 Vault는 새 엔티티를 만들고, 해당 엔티티가 이미 존재하지 않으면 새 별칭을 붙입니다. 엔티티 식별자는 인증된 토큰에 연결되며, 그런 토큰이 사용되면 엔티티 식별자가 감사 기록되어 특정 사용자가 수행한 작업의 흔적을 남깁니다.
Vault 엔티티는 Vault 클라이언트 수를 세는 데 사용됩니다. 클라이언트 수에 대한 자세한 내용은 클라이언트 수(Client Count) 문서를 참조하세요.
엔티티 관리 (Entity management)
Vault의 엔티티는 어디에서도 식별 정보를 자동으로 가져오지 않습니다. 운영자가 명시적으로 관리해야 합니다. 이는 Vault에 동기화할 엔티티 수를 관리적으로 제어하는 데 유연합니다. 어떤 의미에서 Vault는 신원의 캐시 역할을 하지 원천(source) 역할은 하지 않습니다.
Vault Enterprise는 외부 신원 플랫폼에서 엔티티와 내부 그룹을 만들고 관리하는 워크플로우를 위한 베타 SCIM 프로비저닝도 지원합니다.
엔티티 정책 (Entity policies)
Vault 정책은 엔티티에 할당될 수 있으며, 토큰의 기존 정책 위에 추가적인 권한을 토큰에 부여합니다. API 요청에 제시된 토큰이 엔티티 식별자를 포함하고 그 엔티티에 정책 집합이 있으면, 그 토큰은 엔티티의 정책이 허용하는 작업도 수행할 수 있습니다.
이것은 토큰 정책이 언제 평가되는지에 대한 패러다임 전환입니다. Identity 이전에는 토큰의 정책 이름이 불변이었습니다(정책 내용은 불변이 아니지만). 그러나 엔티티 정책과 함께, 토큰의 불변 정책 이름 집합에 더해 그 Identity를 통해 토큰에 적용되는 정책의 평가가 요청 시점에 일어납니다. 이는 이미 발급된 토큰의 동작을 제어하는 엄청난 유연성을 더합니다.
엔티티의 정책은 추가적인 능력만 부여하는 수단이며 토큰의 정책을 대체하지 않는다는 점이 중요합니다. 엔티티 식별자와 연결된 토큰의 전체 능력 집합을 알려면 토큰의 정책도 함께 고려해야 합니다.
참고: 읽기 전용이 아닌 identity 엔드포인트에 권한을 부여할 때는 주의하세요. 사용자가 엔티티를 수정할 수 있으면 정책으로 추가 권한을 부여할 수 있고, 별칭을 수정할 수 있으면 더 높은 권한의 엔티티에 바인딩할 수 있으며, 그룹 구성원을 수정할 수 있으면 더 높은 권한의 그룹에 자신의 엔티티를 추가할 수 있습니다.
마운트 바운드 별칭 (Mount bound aliases)
Vault는 여러 인증 백엔드를 지원하고, 같은 유형의 인증 백엔드를 다른 마운트 경로에 활성화할 수도 있습니다. 사용자의 별칭 이름은 백엔드의 마운트 안에서 고유합니다. 하지만 Identity 스토어는 이 신원 제공자의 다른 마운트들 사이에서 충돌하는 별칭 이름을 고유하게 구분해야 합니다. 따라서 별칭 이름과 인증 백엔드 마운트의 accessor 조합이 별칭의 고유 식별자 역할을 합니다.
아래 표는 각 지원 인증 메서드가 별칭 이름을 만드는 데 사용하는 정보를 보여줍니다.
| Auth method | Name reported by auth method |
|---|---|
| AliCloud | Principal ID |
| AppRole | Role ID |
| AWS IAM | iam_alias로 구성 가능: Role ID(기본), IAM unique ID, Canonical ARN, Full ARN 중 |
| AWS EC2 | ec2_alias로 구성 가능: Role ID(기본), EC2 instance ID, AMI ID 중 |
| Azure | Subject (JWT claim에서) |
| Cloud Foundry | App ID |
| GitHub | 토큰과 연결된 사용자 로그인 이름 |
| Google Cloud | iam_alias로 구성 가능: Role ID(기본), Service account unique ID 중 |
| JWT/OIDC | user_claim으로 제시된 claims 중 구성 가능(기본값 없음) |
| Kerberos | Username |
| Kubernetes | alias_name_source로 구성 가능: Service account UID(기본), Service account name 중 |
| LDAP | Username |
| OCI | Role name |
| Okta | Username |
| RADIUS | Username |
| TLS Certificate | Subject CommonName |
| Token | entity_alias(제공된 경우) |
| Username (userpass) | Username |
로컬 인증 메서드 (Local auth methods)
Vault Enterprise: 모든 인증 메서드는 토큰 저장소를 제외하고 토큰 발급 시 기본적으로 엔티티를 생성합니다. 이는 클러스터 간 공유 마운트와 클러스터 로컬 인증 마운트(local=true 사용) 모두에 적용되며, Vault 복제를 사용할 때 해당됩니다.
로컬 인증 마운트가 만든 엔티티도 여전히 다른 클러스터로 복제됩니다. 다만 로컬 인증 마운트에 관련된 데이터(관련 별칭 포함)를 엔티티 메타데이터에서 제외하면 복제되지 않도록 방지할 수 있습니다.
암시적 엔티티 (Implicit entities)
운영자는 인증 마운트의 모든 사용자에 대해 엔티티를 미리 만들고 정책을 할당해, 사용자가 로그인할 때 원하는 능력을 이미 할당할 수 있습니다. 하지만 그렇게 하지 않으면, 어떤 인증 백엔드에서 사용자가 성공적으로 로그인하면 Vault는 새 엔티티를 만들고 성공한 로그인에 별칭을 할당합니다.
토큰 인증 백엔드로 생성된 토큰은 보통 관련 신원 정보가 없습니다. allowed_entity_aliases 목록이 구성된 토큰 역할로 토큰을 만들 때 entity_alias 파라미터를 사용해 기존 또는 새 암시적 엔티티를 할당할 수 있습니다.
Identity 감사 (Identity auditing)
API 호출에 사용된 토큰이 연결된 엔티티 식별자를 가지면 그것도 감사 기록됩니다. 이는 특정 사용자가 수행한 작업의 흔적을 남깁니다.
Identity 그룹 (Identity groups)
Vault Identity는 그룹(group) 을 지원합니다. 그룹은 여러 엔티티를 구성원으로 포함하고 하위 그룹(subgroup)을 가질 수 있습니다. 그룹에 설정된 정책은 그룹의 모든 구성원에게 부여됩니다. 요청 시점에 토큰의 엔티티 ID가 접근 가능한 정책에 대해 평가될 때, 그룹 구성원 자격으로 상속된 정책이 엔티티 자체의 정책과 함께 부여됩니다.
그룹 계층 권한 (Group hierarchical permissions)
엔티티는 그룹의 직접 구성원일 수 있으며, 이 경우 속한 그룹의 정책을 상속합니다. 엔티티는 그룹의 간접 구성원일 수도 있습니다. 예를 들어 GroupA가 GroupB를 하위 그룹으로 가지면 GroupB의 구성원은 GroupA의 간접 구성원입니다. 따라서 GroupB의 구성원은 GroupA와 GroupB 양쪽의 정책에 접근할 수 있습니다.
외부 그룹 vs 내부 그룹 (External vs internal groups)
기본적으로 Identity 스토어에서 생성된 그룹을 내부 그룹(internal groups) 이라고 합니다. 이 그룹의 구성원 관리는 수동으로 수행해야 합니다.
그룹은 외부 그룹(external group) 으로도 만들 수 있습니다. 이 경우 그룹의 엔티티 구성원은 반자동으로 관리됩니다. 외부 그룹은 Identity 스토어 밖에 있는 그룹에 대한 매핑 역할을 합니다. 외부 그룹은 정확히 하나의 별칭만 가질 수 있으며, 이 별칭은 Identity 스토어 밖의 그룹 개념에 매핑되어야 합니다.
예를 들어 LDAP의 그룹과 GitHub의 팀이 있습니다. LDAP의 그룹에 속한 LDAP 사용자 이름은 로그인과 토큰 갱신 중에 그 엔티티 ID가 Vault의 그룹 구성원으로 자동 추가될 수 있습니다. 이는 Vault의 그룹이 외부 그룹이고 LDAP의 그룹에 매핑되는 별칭을 가질 때만 작동합니다.
참고: 사용자가 LDAP 그룹에서 제거되면 즉시 Vault의 외부 그룹에서 제거되지 않습니다. 그룹 구성원 변경은 이후 로그인 또는 갱신 연산에서만 반영됩니다.