End User Certificate Authentication

Hi,

My company uses SSL certificate authentication via a whitelist of certificates allowed to connect to user services in Apache, however, we now want to have this same functionality in our Ingress Gateway, I was wondering if there’s a way to do this with any of the following:

  1. EnvoyFilter
  2. Mixer Policy
  3. mTLS configuration

I’ve been using Istio for our internal mesh so far and don’t have much experience with Gateways.

Can anyone help me solve this doubt?

Let me make sure I understand what you’re asking for. These SSL certificates, are they for the servers or clients?

If clients, then no, we don’t support that with certificates not generated by Citadel, at least not yet.

Yes, this is how we modeled it:

  1. Request from client comes in to Ingress Gateway
  2. Ingress Gateway checks certificate fingerprint against a whitelist
    2.1) If fingerprint exists in whitelist (populated by a secret), request enters the cluster
    2.2) If fingerprint doesn’t exist, request is rejected

My investigation has led me to either an EnvoyFilter (native to Istio/Envoy) or using Gloo with a function level route that will check this, however, I’d like to keep Istio’s Ingress Gateway if possible.

It looks like the Envoy client_ssl_auth filter has exactly the same support for this: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/ssl#authentication-filter, but I think it doesn’t support to get the fingerprint from a secret. Istio doesn’t support this directly (you can use it with EnvoyFilter as you mentioned).

I’m also curious what’s the use case here? Would you mind to provide some more context about why do you want to use fingerprint here? Would it make sense to support this in the authorization level?

Yes, that’s exactly what we’re going for!

Our use case is fairly specific (or at least I think so), our clients are banking institutions which are notoriously slow to adopt new technologies, which makes adopting JWT or even OAuth very difficult, the particular service that is going to implement this is going to be called from a Cobol application that won’t support any form of authentication.

We also decided against Basic auth or API keys because our clients rarely secure them or use them correctly (that’s without taking into account all security issues).

We don’t have a specific requirement for it to be a fingerprint auth, what we need is client authentication via SSL certificates (this would include mTLS + checking client identity via SSL certificate), which, to my understanding isn’t fully done by enabling mTLS.

I think it if Istio could auth against an IP/Cert hash/Cert fingerprint list would be great, but I can’t ascertain how popular would that auth method be.

You should be able to use the xfcc header that envoy (istio ingress gateway) already populates and a route directive adapter to accomplish this.