Proving Identity Is The Hardest Part of mTLS
mTLS has significant security advantages, but it also has some implementation challenges such as the establishment of secure mechanisms for services to prove their identity to each other.
Regular TLS used to be hard to manage the certificates to prove the identity of a server to their respective clients. Thanks to Let’s Encrypt and the ACME protocol this has become much easier.
The management of service identity and the associated certificates in a dynamic, mostly private, environment such as a Kubernetes cluster is harder due to the various services that need a a strong, provable identities, but this is not practical to use the public ACME service.
There are risks as well as impracticalities when rolling your own automated certificate management system. Getting mTLS certificate management done right is hard. The consequences of getting it wrong are bad. A trusted and proven way to manage such certificates is a must, and this is achieved via a service mesh. This is purpose built to provide the necessary infrastructure needed to safely and securely implement mTLS between services.
The NIST Standard For Microservices Security - A Service Mesh
The National Institute of Standards and Technology (NIST) recommends the use of a service mesh for any dedicated infrastructure layer that provides core network and security features.
One such core feature is the strong service identity and certificate management that is required to support mTLS.
Istio, which is the most widely used service mesh, gives you mTLS support out of the box. It provides the infrastructure with transparent secure naming, strong service identity, and certificate management allowing for secure communications between your Kubernetes workloads as well as connections coming from the public internet.
Istio—the most widely used service mesh—gives you mTLS support out of the box. Istio transparently provides the infrastructure—including secure naming, strong service identity, and certificate management—for secure communications between your Kubernetes workloads as well as for connections to and from the outside world.
Reference:
Leave a Reply