Usages of InsecureSkipVerify: true about audit-kubernetes HOT 2 CLOSED

I think there's a cert pinning finding here too... reading through the docs, we get this:

Trusting the cluster root CA from an application running as a pod usually requires some extra application configuration. You will need to add the CA certificate bundle to the list of CA certificates that the TLS client or server trusts. For example, you would do this with a golang TLS config by parsing the certificate chain and adding the parsed certificates to the RootCAs field in the tls.Config struct.

So, there's likely to be certain portions of keys in the PKI that aren't within the known certs and can't be verified; likewise, there isn't really cert pinning or the like for components, and bundles are copied over. Therefore, attackers who can request certs, attackers who can modify the bundle, &c. could all attack the above that Dominik pointed out. Clearly they need to have some level of self-signed certs (for the root), but if they're copying over the bundles they can pretend to have a real PKI with CA/IA, so why InsecureSkipVerify and not cert pin (or at least TOFU ala HSTS/HPKP).

So, how do they fix:

1. Don't use InsecureSkipVerify, instead head in the direction that kubeadm is going and download certs as part of the install
2. Use an actual PKI: if the Root CA is to be the cluster CA then make it the cluster CA and have an actual process for handling certs via the same
3. Use Cert Pinning, HSTS, HPKP, TOFU, whatever, and enforce it for critical components like the API server and kube-proxy
4. Implement OCSP Stapling to minimize contact with root CA

@tomsteele @btonic @disconnect3d thoughts?

from audit-kubernetes.

TOA-K8S-013

from audit-kubernetes.