Kubernetes has rapidly become one of the most widely used tools for managing containerized applications. The 2021 Cloud Native Computing Foundation Annual Survey found that 96% of the more than 2300 Kubernetes-specific respondents were either already using Kubernetes or evaluating it. In addition, the survey identified 5.6 million Kubernetes users, an increase of nearly 70% in a single year.
Accordingly, Kubernetes is also a common target for cyberattacks. In a survey by Veritas Technologies, 94% of respondents expressed concern about ransomware attacks on Kubernetes environments, and 56% have already suffered at least one such attack.
Unfortunately, many organizations are rushing ahead with Kubernetes deployments before fully understanding all relevant security issues. By doing so, they are unnecessarily increasing their attack surface and exposing themselves to hacks.
There are many steps companies can take to secure their Kubernetes workloads. One best practice that Kubernetes itself recommends is the extensive use of transport layer security (TLS). TLS helps prevent traffic sniffing in a client-server connection by verifying the server and encrypting the traffic between the client and server.
An even better option that developers should apply everywhere possible is mutual TLS (mTLS). This article discusses the benefits of mTLS and how developers can use it to their advantage to frustrate would-be attackers.
What is mTLS?
Mutual TLS takes TLS to the next level by authenticating both sides of the client-server connection before exchanging communications. This may seem like a common-sense approach, but there are many situations where the client’s identity is irrelevant to the connection.
When only the server’s identity matters, standard unidirectional TLS is the most efficient approach. TLS uses public-key encryption, requiring a private and public key pair for encrypted communications. To verify the server’s identity, the client sends a message encrypted using the public key (obtained from the server’s TLS certificate) to the server. Only a server holding the appropriate private key can decrypt the message, so successful decryption authenticates the server.
To have bi-directional authentication would require that all clients also have TLS certificates, which come from a certificate authority. Because of the sheer number of potential clients (browsers accessing websites, for example), generating and managing so many certificates would be extremely difficult.
However, for some applications and services, it can be crucial to verify that only trusted clients connect to the server. Perhaps only certain users should have access to particular servers. Or maybe you have API calls that should only come from specific services. In these situations, the added burdens of mTLS are well worth it. And if your organization reinforces security with zero trust policies where every attempt to access the server must be verified, mTLS is necessary.
mTLS adds a separate authentication of the client following verification of the server. Only after verifying both parties to the connection can the two exchange data. With mTLS, the server knows that a trusted source is attempting to access it.
How is mTLS useful for securing Kubernetes?
mTLS is generally valuable for defeating a variety of attacks. Among the attacks mTLS can fend off are:
- Phishing attacks: Phishing remains one of the most effective ways for hackers to access corporate networks. In fact, in 2021, the number of phishing attempts reached its highest level on record. Hackers have many different ways to compromise credentials and have been very successful in doing so. However, they cannot use those credentials to access servers without the necessary TLS certificate and associated private key for an mTLS-secured connection. Sensitive data and systems remain secure.
- Brute force attacks: Just as with phishing attacks, even if hackers can use brute force methods (e.g., dictionary attacks) to compromise user credentials, they cannot invade connections secured with mTLS.
- Malicious API requests: Many attackers attempt to use API calls to damage corporate systems or exfiltrate data. Malicious API calls can be an effective vector for injecting malware (including ransomware) or even initiating DDoS attacks. But if the API connection requires mutual authentication, attackers will have more difficulty getting access.
- Man-in-the-middle attack: In a man-in-the-middle (MitM) attack, the hacker injects itself between the server and the client, eavesdropping on or even altering communications between the two. While TLS provides some security against MitM attacks, it often fails to defeat them. mTLS adds an extra layer of authentication that further complicates the efforts of MitM attackers and further reduces their chances of success.
With Kubernetes, many different communication pathways can benefit from mTLS, particularly communications between microservices and communications between microservices and any API server. Using mTLS secures these communications without needing any specific identity management or verification process at the application level.
Containerized applications may include many different microservices that exchange data, including sensitive customer data. mTLS keeps hackers from intercepting these communications and creating a data breach.
mTLS also gives you added visibility into potential attacks. Just as with other tools that give you real-time information on anomalous behaviors (network traffic analysis tools like BlueHexagon, website alteration and defacement monitoring tools like Visualping, etc.), by reviewing audit logs, you can quickly pick up unauthorized activity.
Finally, mTLS need not create added difficulties for the user. Instead, properly implemented, mTLS can give users an added sense of security without extra complexity, enhancing the overall user experience. When mTLS acts at the platform level, only a single authentication action is necessary. Users don’t have to reauthenticate for every microservice within the application.
Practical considerations for using mTLS with Kubernetes
While using mTLS in your Kubernetes environment can give you an added comfort level about security, it comes with a cost. That cost comes from the need for an effective certificate provisioning and management system.
When applying mTLS widely in a Kubernetes container deployment, recall that many clients are individual services. Each of these services will need its own certificate, and there will be many.
In addition, Kubernetes services, by their very nature, are impermanent. With replicas of Kubernetes services being created and destroyed dynamically, the challenge of managing certificates can be daunting.
Your certificate management system must also be robust enough to handle the deprovisioning and reprovisioning of certificates according to your internal security policies. If, like many, you rely on certificate rotation (giving certificates limited lifetimes and issuing new certificates on expiration) to minimize the chances that a hacker can exploit them, you must be able to assign new certificates to all affected services quickly.
Fortunately, many different tools are available to help you easily manage certificates, even if you have a massive number of certificates for your Kubernetes services.
Conclusion
As more and more businesses transition to containerization and the use of container orchestration services like Kubernetes, more need will exist for effective and efficient methods for securing data flows between services in the containers. By applying mTLS at every point where it is possible, developers can reduce an application’s attack surface and minimize the risk that a hacker can access sensitive data and systems.
