승인(인가)에 컨트롤 그룹 사용하기
승인(인가)에 컨트롤 그룹 사용하기
Enterprise
적절한 Vault Enterprise 라이선스 또는 HCP Vault Dedicated 클러스터가 필요합니다.
Vault Enterprise는 컨트롤 그룹 승인(Control Group Authorization)을 지원합니다. 컨트롤 그룹은 요청을 처리하기 전에 추가적인 승인 요소를 요구하도록 만듭니다.
요청에 컨트롤 그룹이 요구되면, 요청된 데이터 대신 제한된 기간의 응답 래핑(response wrapping) 토큰이 사용자에게 반환됩니다. 응답 래핑 토큰의 접근자(accessor)는 컨트롤 그룹 정책이 요구하는 승인자들(approver)에게 전달될 수 있습니다. 모든 승인이 만족되면 래핑 토큰을 사용해 원래 요청을 풀고(unwrap) 처리할 수 있습니다.
컨트롤 그룹 팩터
컨트롤 그룹은 다음 팩터를 검증할 수 있습니다.
Identity Groups— 승인자가 특정 아이덴티티 그룹 집합에 속하도록 요구합니다.
제어된 기능(Controlled capabilities)
컨트롤 그룹 팩터는 특정 기능에 대해 컨트롤 그룹 워크플로를 트리거하도록 구성될 수 있습니다. 이는 controlled_capabilities 필드로 수행합니다. controlled_capabilities 필드를 지정하지 않으면 지정된 정책 경로에 대한 모든 작업에 대해 팩터를 확인해야 합니다. controlled_capabilities 필드는 팩터마다 다를 수 있으므로 다른 작업에 다른 팩터를 요구할 수 있습니다.
마지막으로, controlled_capabilities 스탠자의 기능은 정책 자체에 지정된 capabilities의 부분 집합이어야 합니다. 예를 들어, secret/foo 경로에 read 접근만 부여하는 정책은 list를 제어된 기능으로 가진 컨트롤 그룹 팩터를 지정할 수 없습니다.
예시는 다음 섹션의 ACL 정책을 참고하세요.
ACL 정책의 컨트롤 그룹
경로에 대한 컨트롤 그룹 요구 사항은 다른 ACL 매개변수와 함께 control_group으로 지정됩니다.
샘플 ACL 정책
path "secret/foo" {
capabilities = ["read"]
control_group = {
factor "ops_manager" {
identity {
group_names = ["managers"]
approvals = 1
}
}
}
}
위 정책은 "managers" 그룹의 구성원 1명이 요청을 승인한 후에만 secret/foo에 대한 read 접근을 부여합니다.
path "secret/foo" {
capabilities = ["create", "update"]
control_group = {
ttl = "4h"
factor "tech leads" {
identity {
group_names = ["managers", "leads"]
approvals = 2
}
}
factor "super users" {
identity {
group_names = ["superusers"]
approvals = 1
}
}
}
}
위 정책은 "managers" 또는 "leads" 그룹의 구성원 2명과 "superusers" 그룹의 구성원 1명이 요청을 승인한 후에만 secret/foo에 대한 create와 update 접근을 부여합니다. 승인자가 "managers"와 "superusers" 그룹 모두의 구성원이라면, 두 팩터 모두에 대해 하나의 승인으로 만족됩니다.
path "secret/foo" {
capabilities = ["write","read"]
control_group = {
factor "admin" {
controlled_capabilities = ["write"]
identity {
group_names = ["admin"]
approvals = 1
}
}
}
}
위 정책은 이 정책이 있는 Vault 토큰을 가진 누구에게나 secret/foo에 대한 read 접근을 부여합니다. admin 그룹의 구성원 1명이 요청을 승인한 후에만 secret/foo에 대한 write 접근을 부여합니다.
path "kv/*" {
capabilities = ["create", "update","delete","list","sudo"]
control_group = {
factor "admin" {
controlled_capabilities = ["delete","list","sudo"]
identity {
group_names = ["admin"]
approvals = 1
}
}
}
}
path "kv/*" {
capabilities = ["create"]
control_group = {
factor "superuser" {
identity {
group_names = ["superuser"]
approvals = 2
}
}
}
}
두 번째 경로 스탠자는 controlled_capabilities 필드가 없는 컨트롤 그룹 팩터를 가지므로, 이 정책이 있는 모든 토큰은 kv/*에 대해 어떤 작업이든 실행하기 전에 "superuser" 그룹의 승인 2개를 받아야 합니다. 추가로 첫 번째 경로 스탠자의 controlled_capabilities 필드 덕분에 delete, list, sudo 작업은 "admin" 그룹의 추가 승인이 필요합니다.
path "kv/*" {
capabilities = ["read", "list", "create"]
control_group = {
controlled_capabilities = ["read"]
factor "admin" {
identity {
group_names = ["admin"]
approvals = 1
}
}
factor "superuser" {
controlled_capabilities = ["create"]
identity {
group_names = ["superuser"]
approvals = 1
}
}
}
}
이 경우 read는 admin 승인 1개가 필요하고 create는 superuser 승인 1개와 admin 승인 1개가 필요합니다. List는 어떤 컨트롤 그룹 팩터의 추가 승인도 필요하지 않으며, 이 정책이 있는 토큰은 kv/*에 대해 읽기 작업을 실행하기 위해 컨트롤 그룹 워크플로를 거칠 필요가 없습니다.
Sentinel의 컨트롤 그룹
컨트롤 그룹은 controlgroup 임포트를 사용해 Sentinel 정책에서도 지원됩니다. 사용 가능한 속성에 대한 자세한 내용은 Sentinel 문서를 참고하세요.
샘플 Sentinel 정책
import "time"
import "controlgroup"
control_group = func() {
numAuthzs = 0
for controlgroup.authorizations as authz {
if "managers" in authz.groups.by_name {
if time.load(authz.time).unix > time.now.unix - 3600 {
numAuthzs = numAuthzs + 1
}
}
}
if numAuthzs >= 2 {
return true
}
return false
}
main = rule {
control_group()
}
위 정책은 "managers" 그룹의 구성원 2명이 요청을 승인하지 않으면 요청을 거부합니다. 추가로 승인이 지난 1시간 안에 일어났는지도 검증합니다.
튜토리얼
정책 내에서 이중 컨트롤러 승인을 구현하는 방법을 배우려면 컨트롤 그룹 튜토리얼을 참고하세요.
API
컨트롤 그룹은 HTTP API로 관리할 수 있습니다. 자세한 내용은 컨트롤 그룹 API를 참고하세요.
출처: 문서