mTLS authN mode

[guicassolato]

There's already a placeholder for it at https://github.com/3scale-labs/authorino/blob/2b6a6f8016a5837650506cd125751f8d95ea4197/pkg/config/identity/mtls.go.

[guicassolato]

Implementation for this could involve having the CA certs stored in kubernetes.io/tls-type Secrets, having such secrets labelled as "managed-by" Authorino, similarly to how it's currently done for API keys.

In the case of Authorino API keys, however, each Kubernetes Secret represents one identity, where specific user info can be stored, e.g., in the annotations of the secrets. For the mTLS implementation, on the other hand, each Secret would represent not a specific user identity, but a trusted authority which can sign any number of user/client certificates – i.e., an "issuer of identities".

Without storing SANs/CNs anywhere, mTLS authentication in Authorino will probably be limited to

1. verification of the (root) CA signature, and
2. validity in time ("notBefore" and "notAfter" fields).

This limitation is similar to the current support for the verification of OpenID Connect JWTs in Authorino.

Some authorization policies can still be implemented based on SANs/CNs and/or other fields of the certificate. However considering X.509 certificates are usually not very complex structures (unlike JWTs), any additional user data will likely have to be fetched from external services in request-time, using Authorino HTTP GET/GET-by-POST metadata.

Revocation is another issue to consider. Unless we're planning on supporting certificate revocation lists (see https://datatracker.ietf.org/doc/html/rfc2459#section-3.3 for more info), issued certificates shall be valid until they expire. While for OIDC UserInfo metadata can be still be fetched in request-time as a workaround to prevent revoked tokens access, for mTLS such revocation lookup would have to be implemented by the user, again leveraging Authorino HTTP GET/GET-by-POST metadata

[guicassolato]

A reference about the client cert revocation issue: kubernetes/kubernetes#18982

[guicassolato]

We should also make sure people interested in this feature in Authorino still have the option of using Keycloak's X.509 Client Certificate User Authentication and later Authorino only to verify the token via the OIDC token verification feature.

[jsmadis]

I will try to follow up with Gui's ideas.

Revocation:

1. We support revocation.

• We introduce an option to enable CRL checking (user can disable it [opt-out]). We can get the CRL:
  • in the request time. We will fetch the CRLs. Not optimal, it will increase the request time. Basically, it's the same as using HTTP GET/GET-by-POST metadata.
  • load from a file. We will load the file with CRLs and check if the current certificate was revoked. Basic idea is that we will look for a secret/config map with CRLs (a user can add it manually or it can be downloaded from the CA). For example, for the download of the CRL, we can introduce a cron job (or use Kubernetes one) and get the CRL in some periodic time (this can be done outside authorino), save it to the secret/config map. Then we can go through the secrets watched by authorino and label secrets that are revoked (I wouldn't remove them since they are created by the user). Or we can cache the CRL and check the certs during request time.

Another way would be downloading the CRLs (from CA) during the reconciliation, but since the reconciliation is not periodic and some CRDs might be a long period of time without reconciliation it would not be suitable for this use case.

2. We won't support revocation and the certificates are valid until they expire or users delete them from the cluster.

[guicassolato]

2. We won't support revocation and the certificates are valid until they expire or users delete them from the cluster.

I think we could start with this option in the beginning, and then either evolve to CRLs or advise clients to use Keycloak for a 1st leg of authentication based on mTLS followed by requests to the protected service using the access token.

[guicassolato]

To sum up a few options we have for supporting mTLS authn in Auhtorino:

1. Rely on Keycloak → clients first exchange a client TLS cert for an even shorter-lived access token and Authorino only validates this token
   • no real support for mTLS offered by Authorino
   • requires pre-flight request to authenticate on Keycloak, then actual requests to consume the API (like OIDC)
   • a lot more options for authz using jwt claims
2. Rely on Istio → Istio validates the cert and Envoy passes the cert attributes, post-authn, as metadata, to Authorino, for the authorization policies (?)
   • no real support for mTLS offered by Authorino
   • authentication not really happening in Authorino, though as part of the same request
   • requires to be able to skip the identity phase (see Configurable evaluator response strategies for the phases of the auth pipeline #112)
   • rather an option for Kuadrant (depending less on Authorino), than an option for Authorino itself
3. Own implementation → Authorino is told which CAs to trust (label selectors of tls Secrets specified in the AuthConfigs) and Authorino verifies the issuer of each client cert presented
   • actual real support for mTLS offered by Authorino
   • hard to support revocation (see this comment from @jsmadis)