Vault 프록시로 Vault 트래픽 복원력(탄력성) 개선하기

Enterprise

적절한 Vault Enterprise 라이선스가 필요합니다.

Vault 프록시와 함께 정적 시크릿 캐싱을 사용해 KVv1 및 KVv2 시크릿을 캐시함으로써 Vault로의 요청을 최소화하고 클라이언트에 탄력적인 연결을 제공합니다.

Vault 프록시는 캐시 신선도를 위해 Enterprise 전용인 Vault 이벤트 알림 시스템 기능을 활용합니다. 결과적으로 정적 시크릿 캐싱은 Vault Enterprise 설치에서만 사용할 수 있습니다.

성능 대기(performance standby)가 있는 Vault 클러스터를 사용할 때, 프록시가 시크릿 업데이트가 완전히 복제되기 전에 시크릿 업데이트 이벤트를 받을 수 있습니다.

Vault 프록시 1.21+와 Vault 서버 1.20+를 사용할 때, Vault 프록시는 클라이언트 제어 일관성(client-controlled consistency)으로 불완전한 복제를 자동으로 처리합니다. 필요하면 Vault 프록시는 해당 시크릿 업데이트에 대한 스토리지 인덱스가 노드에 존재할 때까지 보조 노드에서 읽기를 다시 시도합니다.

Vault 프록시 1.20 이하 및/또는 Vault 1.19 이하를 사용한다면, 프록시가 이벤트 알림을 받은 후 갱신된 시크릿 값을 얻을 수 있도록 프록시의 Vault 스탠자에서 활성 노드의 주소를 가리키도록 구성하거나, 클러스터에서 allow_forwarding_via_header를 true로 설정해야 합니다. allow_forwarding_via_header가 구성되면, 프록시는 시크릿이 갱신되었음을 나타내는 이벤트를 받은 후에만 캐시의 시크릿을 갱신하기 위한 요청을 전달합니다. 이 접근 방식은 예를 들어 Vault 접근이 로드 밸런서 뒤에 있을 때 권장됩니다.

1단계: Vault 프록시를 KV 이벤트에 구독시키기

Vault 프록시는 Vault 이벤트와 자동 인증을 사용해 시크릿 상태를 모니터링하고 적절한 캐시 갱신을 수행합니다.

자동 인증(auto-auth)을 켭니다.
Vault 이벤트 알림 시스템을 사용해 KV 이벤트 업데이트를 구독할 권한이 있는 자동 인증 토큰을 만듭니다. 예를 들어, 정적 시크릿(KVv1 및 KVv2) 이벤트에 접근 권한을 부여하는 정책을 만들려면 events 엔드포인트를 구독할 권한과, 시크릿을 얻고자 하는 KV 시크릿에 대한 list 및 subscribe 권한이 필요합니다.
```
 path "sys/events/subscribe/kv*" {
   capabilities = ["read"]
 }

 path "*" {
   capabilities = ["list", "subscribe"]
   subscribe_event_types = ["kv*"]
 }
```

KV 이벤트를 구독한다는 것은 시크릿이 변경되는 즉시 프록시가 갱신을 받는다는 뜻이며, 캐시의 오래된(stale) 상태를 줄여 줍니다. Vault 프록시는 이벤트 알림이 관련 시크릿이 갱신되었음을 알릴 때만 시크릿 업데이트를 확인합니다.

2단계: 토큰이 `capabilities-self` 접근 권한을 갖도록 하기

토큰은 캐시된 시크릿을 요청하려면 sys/capabilies-self 엔드포인트에 대한 update 접근 권한이 필요합니다. Vault 토큰은 기본적으로 update 권한을 받습니다. 기본 정책을 수정했거나 제거했다면, 적절한 권한이 있는 정책을 명시적으로 만들어야 합니다. 예:

  path "sys/capabilities-self" {
    capabilities = ["update"]
  }

3단계: 적절한 새로고침 간격 구성하기

기본적으로 Vault 프록시는 5분마다 토큰을 새로고침합니다. cache 구성 스탠자의 static_secret_token_capability_refresh_interval 매개변수로 기본 동작을 변경하고 캐시된 토큰의 기능을 확인·갱신하도록 프록시를 구성할 수 있습니다. 예를 들어 새로고침 간격을 1분으로 설정하려면:

cache {
  cache_static_secrets = true
  static_secret_token_capability_refresh_interval = "1m"
}

기능

정적 시크릿 캐싱을 사용하면 Vault 프록시가 KVv1 및 KVv2 엔드포인트에 대한 GET 요청을 캐시합니다.

클라이언트가 새 KV 시크릿에 대한 GET 요청을 보내면, 프록시는 요청을 Vault로 전달하되 클라이언트에 전달하기 전에 응답을 캐시합니다. 같은 클라이언트가 같은 시크릿에 대해 이후 GET 요청을 하면, Vault 프록시는 요청을 Vault로 전달하는 대신 캐시된 응답을 제공합니다.

'오프라인' 시크릿 접근과 CLI KV Get

Vault 프록시는 KV가 아닌 API 응답은 캐시하지 않습니다. KV 시크릿은 Vault를 사용할 수 없어도 조회할 수 있지만, 다른 요청은 제공될 수 없습니다. 결과적으로 KV GET 요청보다 앞서 /sys/internal/ui/mounts에 요청을 보내는 vault kv CLI 명령을 사용하는 것은 Vault에 대한 실제 요청이 필요하며, 캐시만으로는 (또는 Vault를 사용할 수 없을 때는) 온전히 제공될 수 없습니다(대신 vault read를 사용할 수 있습니다).

마찬가지로, 토큰이 KV 시크릿에 대한 접근을 요청할 때는 성공적인 GET 요청을 완료해야 합니다. 요청이 성공하면, 프록시는 결과 외에도 토큰이 성공했었다는 사실을 캐시합니다. 그 후 같은 토큰의 후속 요청은 Vault 대신 캐시에서 이 시크릿에 접근할 수 있습니다.

Vault 프록시는 이벤트 알림 시스템을 사용해 캐시를 최신 상태로 유지합니다. 현재 캐시에 저장된 어떤 시크릿과 관련된 이벤트(업데이트나 삭제 같은 수정 이벤트 포함)를 KV 이벤트 피드에서 모니터링합니다. 프록시가 캐시된 시크릿의 변경을 감지하면, 적절히 캐시 항목을 갱신하거나 퇴거합니다.

Vault 프록시는 또한 static_secret_token_capability_refresh_interval로 설정된 창에 따라 알려진 토큰의 접근 권한을 확인하고 새로고침합니다. 기본적으로 새로고침 간격은 5분입니다.

매 간격마다 프록시는 캐시의 모든 토큰을 대신해 sys/capabilies-self를 호출해 토큰이 여전히 캐시된 시크릿에 접근할 권한이 있는지 확인합니다. Vault 결과가 권한(또는 토큰 자체)이 폐기되었음을 나타내면, 프록시는 영향을 받는 토큰이 더 이상 관련 경로를 캐시에서 접근할 수 없도록 캐시 항목을 갱신합니다. 새로고침 간격은 본질적으로 해당 토큰에 대해 KV 시크릿 읽기 권한이 완전히 폐기되는 최대 기간입니다.

기능이 제거되었거나 프록시가 403 응답을 받으면, 그 기능은 토큰에서 제거되고 해당 토큰은 캐시 접근에 사용될 수 없습니다. Vault에 도달할 수 없거나 봉인(sealed)된 것 같은 다른 종류의 오류에 대해서는 static_secret_token_capability_refresh_behavior 구성을 참고합니다. optimistic(기본값)으로 설정하면, 403 또는 기능이 없는 유효한 응답을 받지 않는 한 기능이 제거되지 않습니다. pessimistic으로 설정하면, Vault가 봉인된 경우 발생하는 것 같은 어떤 오류에 대해서도 기능이 제거됩니다.

토큰 새로고침이 동작하려면 캐시에 접근하는 모든 토큰도 sys/capabilies-self에 대한 update 권한이 필요합니다. 토큰에 대한 update 권한이 있으면 프록시는 각 경로에 대해 403 응답을 명시적으로 테스트하는 대신, 단일 요청으로 여러 경로에 대한 토큰의 기능을 테스트할 수 있습니다.

새로고침은 시크릿별이 아니라 토큰별입니다

프록시의 API 프록시가 토큰에 대해 자동 인증을 사용하도록 구성되고, Vault 프록시를 통과하는 모든 요청이 같은 토큰을 사용한다면, 프록시는 현재 캐시된 시크릿 수와 관계없이 새로고침 간격마다 Vault에 단 한 번의 요청만 보냅니다.

정적 시크릿 캐싱이 켜져 있으면, 프록시는 요청에 대한 응답 헤더 X-Cache에 HIT 또는 MISS를 반환해 클라이언트가 응답이 캐시에서 제공되었는지 Vault에서 전달되었는지 알 수 있습니다. 히트(HIT)의 경우 프록시는 Age 헤더도 설정해 캐시 항목이 몇 초나 오래되었는지 표시합니다.

오래된 것이 stale(신선하지 않음)이라는 뜻은 아닙니다

캐시 항목이 오래되었다는 사실이 반드시 정보가 신선하지 않다는 뜻은 아닙니다. Vault 프록시는 KV 이벤트를 계속 모니터링해 갱신합니다. Age 값이 크다는 것은 단지 시크릿이 최근에 회전(rotate)되지 않았다는 뜻일 수 있습니다.

구성

최상위 cache 블록에는 정적 시크릿 캐싱과 관련된 다음 구성 항목이 있습니다.

cache_static_secrets (bool: false) — true로 설정하면 정적 시크릿 캐싱을 켭니다. cache_static_secrets와 auto_auth가 모두 켜져 있으면, Vault 프록시는 충분한 권한이 있는 클라이언트에게 KV 시크릿을 캐시에서 직접 제공합니다.
static_secret_token_capability_refresh_interval (duration: "5m", optional) — Vault 프록시가 캐시된 시크릿에 접근하는 데 사용되는 토큰의 권한을 다시 확인하는 간격을 기간 형식 문자열로 설정합니다. 이 새로고침 간격은 캐시된 KV 시크릿 읽기 권한이 완전히 폐기되는 최대 기간입니다. cache_static_secrets가 false일 때는 무시됩니다.
static_secret_token_capability_refresh_behavior (string: "optimistic", optional) — 기능을 새로고침하려다 오류가 났을 때의 기능 새로고침 동작을 설정합니다. 403의 경우 두 옵션 모두 토큰에서 기능이 제거됩니다. Vault가 봉인되었거나 Vault에 접근할 수 없는 것 같은 다른 오류의 경우 이 설정이 동작을 제어합니다. optimistic(기본값)으로 설정하면 403 오류에 대해서만 기능이 제거됩니다. pessimistic으로 설정하면 어떤 오류에 대해서도 기능이 제거됩니다. 이는 본질적으로 캐시된 정적 시크릿의 가용성(optimistic)과 접근 정확성(pessimistic) 중 어느 쪽을 선호할지 구성하는 것입니다. cache_static_secrets가 false일 때는 무시됩니다.

예시 구성

다음 Vault 프록시 구성 예시는:

TLS가 비활성화된 TCP 리스너(listener)를 정의합니다.
API 프록시(api_proxy)를 사용하는 클라이언트가 자동 인증 토큰으로 신원을 밝히도록 강제합니다.
approle에 대한 자동 인증(auto-auth)을 구성합니다.
cache_static_secrets로 정적 시크릿 캐싱을 켭니다.
static_secret_token_capability_refresh_interval로 1시간의 명시적 토큰 기능 새로고침 창을 설정합니다.

# 다른 Vault 프록시 구성 블록
# ...

cache {
  cache_static_secrets = true
  static_secret_token_capability_refresh_interval = "1h"
}

api_proxy {
  use_auto_auth_token = "force"
}

listener "tcp" {
    address = "127.0.0.1:8100"
    tls_disable = true
}

auto_auth {
  method {
    type = "approle"
    config = {
      role_id_file_path = "roleid"
      secret_id_file_path = "secretid"
      remove_secret_id_file_after_reading = false
    }
  }
}

출처: 문서

Vault 프록시로 Vault 트래픽 복원력(탄력성) 개선하기