Ingress client certificate authenticate requires CA certificate to be stored in secret?

Question

I want to enable client-certificate authentication in my AKS cluster and I have a basic question which I just don't seem to understand. As per the docs, ingress requires the CA certificate to be stored in a secret. My question is: Assuming that I use client-certificates that have been issued by a trusted CA (that's how it works right? CAs issue client-certificates that they sign?), why would a trusted CA give me their CA certificate to be stored in AKS cluster as a secret? Do CAs just hand out their certificates out to public? Isn't that a security issue? (since I can sign client-certificates using that CA certificate)

Answer 1

In the context of X.509, which is used in TLS, we usually use the term “certificate” to refer to a structure which contains, along with identifying information, a public key. Since this key is public and the certificate is generally available to anyone on the Internet, there's no risk in providing it. It probably needs to exist in a secret store only because it's a convenient place to load it from, not because it's actually secret.

What you're probably thinking of is the private key corresponding to the public key in the certificate, which you of course won't be able to access. Publicly trusted CAs usually store the private key in a hardware security module, so even the people running the CA probably can't access it (only use it to sign things).

Answer 2

Certificates are intended to be public.

Do CAs just hand out their certificates out to public? Isn't that a security issue?

Yes, CAs do hand out their certificates. And no, this is not a security issue. Any CA is considered as trusted only if you know its certificate. In some cases, for manual verification knowledge of fingerprint may be sufficient. But in many cases for trust a knowledge of certificate is needed. Technically, it means that CA is trusted only if its certificate is stored in your trust store. That's making certificates publicly available is not a security issue. It is even vice versa: CAs want that their certificates are broadly known and are accepted (and stored in trust stores) by as many parties as possible.

When you install some operation system, Windows, Linux, no matter what, also certificates of trusted CAs will be installed. When you install FireFox, also certificates of trusted CAs will be installed.

For CAs it is very hard to become trusted and to be included in the install packages of important software, because there is a very strict process for this that requires that CA fulfills many special requirements.

To the secrets: Often applications need passwords to access some external resources. It is unsafe to store such passwords in the application code. Passwords are made available to the application only when application is put to the Kubernetes environment. Kubernetes uses for this a mechanism called secrets. The article you linked uses this mechanism to store certificates. Certificates are not secret. Then why public information like certificates is stored as a secret? This is because the word "secret" is misleading in this context. Better name for "secrets" in Kubernetes would be "credentials" or "authentication data" or something similar.

Answer 3

A "certificate" is a digitally-signed message which says, in a machine-readable language, “<this public key>'s corresponding private key is authorized for <these purposes>”. The language is usually X.509, which stores "these purposes" in the Key Usage bitfield and Extended Key Usage sequence. (If you tried to change either field, it would invalidate the digital signature.)

A "certificate authority" is just any key (or the operator of a key) which computers have been configured to trust such signed messages from.*

If the authority "signs your key for client authentication", they have likely not included keyCertSign in the list of authorized uses; it's probably only been given id-kp-clientAuth. This means that other software which trusts that authority will trust your key to authenticate any client using it directly to negotiate a secured connection, but it will not trust any certificates that your key were to create (even if such certificates only authorized id-kp-clientAuth).

---

*In this case, you are creating a Certificate Authority, but (obviously) only your cluster is configured to trust certificates from it.

Note: The CA Certificate must contain the trusted certificate authority chain to verify client certificates. … For more details on the generation process, checkout the Prerequisite docs].

If sg1993's Cert Authority (that you generated back during the prerequisite stage) certifies a key for use as a client, server, or anything else, such certificates will only be respected or recognized by software that's been configured to do so (i.e.: that you've installed the CA's key on).

Usually you would obtain this from a trusted source, but for this example we will just create one.

Answer 4

An initial point to note here is that the documentation you link to is for implementing Client certificate authentication for applications running on your cluster using an ingress resource, not for the AKS cluster itself.

In terms of why they're suggesting you store the information in a secret, there's actually a couple of pieces of information being stored here. First is a CA certificate which, as has been pointed out in other answers, is public information, so no problem there.

The other piece is the private key for your server alongside its certificate. It's that key that is important to maintain the security over, as anyone with that key can impersonate your server.