P
Prominent Marmoset
Description:
We need a second layer of protection for our Harness tenant that goes beyond validating client certificates via the root of trust (i.e., CA-based validation). Specifically, we require support for client identity authorization based on Subject Alternative Name (SAN) fields in the client certificate.
Current Behavior:
Harness’s Envoy-based mTLS implementation performs certificate validation via CA trust (root of trust), but does not currently verify the client identity (e.g., via SAN).
Requested Enhancement:
  • Add support to authorize client identity via SAN fields in the client certificate.
  • Allow customers to configure an allowlist of permitted identities (e.g., specific SAN values) via a tenant-level setting.
  • This configuration should be exposed through existing elevated privilege mechanisms, such as those used for managing tenant-wide properties (like IDP integrations).
  • Harness should enforce that incoming requests to the customer tenant originate from a pre-authorized identity, not just a certificate issued by the customer's CA.
Business Justification:
This feature will help prevent unauthorized internal services (with valid customer-issued certs) from accessing the Harness tenant without explicit identity-level authorization.
Created by Gino Orvieto
·