Cloud Hosting

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.

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 clients identity is irrelevant to the connection.

When only the servers 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 servers identity, the client sends a message encrypted using the public key (obtained from the servers 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.

mTLS is generally valuable for defeating a variety of attacks. Among the attacks mTLS can fend off are:

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 dont have to reauthenticate for every microservice within the application.

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.

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 applications attack surface and minimize the risk that a hacker can access sensitive data and systems.

Continued here:
Why mTLS Should Be Everywhere in Kubernetes and Not Just Entry and Exit - Security Boulevard