Skip to content
This repository has been archived by the owner on Nov 22, 2023. It is now read-only.

Proposal: Do not require x-forwarded-client-cert header for client identification #812

Open
jbpeirce opened this issue Feb 24, 2021 · 0 comments

Comments

@jbpeirce
Copy link
Contributor

The ClientAuthFactory for Keywhiz clients allows clients to be identified based on

  • the SecurityContext of the connection to Keywhiz
  • a certificate forwarded in the "x-forwarded-client-cert" header (used by the commonly-used Envoy proxy)
  • a client SPIFFE ID in the header identified by the "callerSpiffeIdHeader" in Keywhiz' configuration

The factory currently requires the "x-forwarded-client-cert" header to be set even if the "callerSpiffeIdHeader" is also set. However, if the "callerSpiffeIdHeader" is set, then the "x-forwarded-client-cert" header should not be used to identify the client (since some proxy configurations set both headers but use only the "callerSpiffeIdHeader" to identify the client).

The factory should probably be updated to not require the "x-forwarded-client-cert" header if the "callerSpiffeIdHeader" is set. This will require refactoring some of the existing logic, which ensures that the entity setting an "x-forwarded-client-cert" header is allowed to do so, to separately check whether the entity is allowed to set the "callerSpiffeIdHeader." (Currently, the factory relies on the "x-forwarded-client-cert" check to check whether the entity is allowed to set the "callerSpiffeIdHeader" as well.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant