alcide

Alcide Blog

Cloud-native Security Provider

Using Istio to Secure Service Meshes

Mar 20, 2019 10:51:22 AM / by Gadi Naor

 

Using Istio to Secure Service Meshes

Kubernetes does a great job of being the perfect host for applications that follow the
microservices architecture pattern. A strong, vibrant community of contributors from a wide
spectrum of different organizations, have made sure that it's a robust, secure platform that
represents the state of the art in terms of managing and orchestrating cloud native applications.


It's not a platform that attempts to solve every problem, however, and neither should it be.
Whilst not wishing to diminish its enormous impact on cloud native computing, if we were to imagine Kubernetes as a commodity cloud native operating system for a moment, then there is plenty of scope to use it as a building block for higher level abstractions, and tooling for automation workflows. One such building block is Istio, an open source project founded by Google, IBM and
Lyft.

What is Istio?

Istio is a platform for managing the complexity of microservices deployments, providing the
means to shape the flow of traffic between services, observe the performance and availability of those services, and to secure access to and between peer services. Whilst it's not designed
specifically to run atop Kubernetes, as Kubernetes is the de-facto standard for orchestrating
container-based microservices, it has been designed with Kubernetes very much in mind.
Istio provides its management and control features by deploying a sidecar proxy alongside each service running in a cluster. These proxies, based on the open source Envoy proxy from Lyft, intercept the communication between services, in order to provide management capabilities such as routing, load balancing, service discovery, authentication, authorization and so on. The complex network of services and proxies are referred to as a service mesh, for obvious reasons. The sidecar proxies, which make up the 'data plane' of the service mesh, provide the mechanism for enforcing service mesh policy, whilst Istio's 'control plane' allows for defining the policy, and for configuring the proxies in line with the defined policy.

 

Security Features in Istio

Istio aims to solve a lot of complex problems, and it has a lot of different features for managing
cloud native services, but in this article we'll home in specifically on the security features that it
provides.

 Source: Istio website

Source: Istio Documentation 

The diagram above provides a high level view of Istio's control plane components, and the interactions that occur between the control plane and the proxies that facilitate the application of security policy. Citadel provides Public Key Infrastructure (PKI), whilst Pilot allows us to configure the data plane according to the policy we define, and Mixer allows us to retrieve telemetry data for observability purposes. Let's take a look at what can be defined by way of security policy.

 

Authentication

When we need to establish secure, encrypted connections between a requesting client and a provider service, we generally tend to use Transport Layer Security (TLS). It's what every web browser uses as the basis for securely communicating with remote servers. It's the job of whoever is responsible for providing particular services, to ensure that the X.509 certificates required to establish TLS, are current, valid and available for each service.
In a microservices world, where there can be hundreds, if not thousands, of ephemeral services interacting with each other, the task of managing certificates, keys and TLS configuration, quickly becomes a significant challenge. Where secure, encrypted service-to-service communication is required, then Istio helps by providing policy-based authentication for the establishment of mutual TLS (mTLS) between a client and the provider service. In fact, not only does it support service-to-service (or transport) authentication for TLS, but Istio also supports end-user (or origin) to service authentication too.

Save your seat!

Identity

A client's ability to authenticate a server, and vice versa, is directly linked to the identity presented by the server. To facilitate authentication, when new services are deployed to a Kubernetes cluster, Istio generates an identity for the service using a Kubernetes service account associated with the service. This identity is embodied in the certificate it creates and signs with its root CA key (courtesy of Citadel) , and which it makes available to the sidecar proxy as a secret mounted in the pod (along with the corresponding private key).
Istio holds a mapping of the identities contained within the certificates it creates, to the services that get deployed in the cluster, and which are discoverable in the network. This allows a client to detect service impersonation when it attempts to consume a service.

And when it comes to authenticating end-user requests to services, Istio uses JSON Web Tokens (JWT) to provide request-level authentication. Policy for JWT authentication can be configured to verify identities using an OpenID provider, such as Auth0 or Keycloak.

 

Mutual TLS

It's great that Istio provides an in-cluster PKI, but won't service authors still need to produce code that concerns itself with creating secure connections using certificates and keys? The short answer is no. When a service attempts to communicate with another service, its request is intercepted by its sidecar proxy, which performs a TLS handshake with the proxy associated with the remote service. Provided that each party can authenticate the other, then a mTLS channel of communication is established. In transposing the responsibility for authentication and mTLS establishment onto the sidecar proxies, the service author is freed from the concern of coding this directly into their application. Instead, they get to concentrate on delivering value, whilst Istio takes care of the ongoing management of certificates and secure connections.

 

Authorization

Istio's handling of authentication across a service mesh is an essential ingredient in securing access to a service's capabilities. But it's not all that's required. It's also important to authorize service requests, and just as we can define authentication policy, so too can we define authorization policy for determining who can do what under a specific set of conditions. Istio's authorization capability needs to be turned on by deploying an appropriately configured RbaConfig object, which also defines the scope of the authorization policy.
The UI for Istio authorization is very similar to that exposed in Kubernetes itself, with a ServiceRole being analogous to a Role or ClusterRole , and a ServiceRoleBinding being analogous to a RoleBinding or ClusterRoleBinding .
A ServiceRole encapsulates a set of rules that relate to services, and the allowed request methods, paths and constraints for accessing them. A ServiceRoleBinding references a ServiceRole , and binds a list of subjects to that ServiceRole. The subjects can be users (service accounts), users with certain properties associated with them (taken from a JWT, for example), or wildcard subjects such as 'all authenticated users'.
The authorization features provided in Istio, then, allow for fine-grained access control to services that run under the jurisdiction of a mesh of sidecar proxies.

 

Securing Istio's Control Plane

Istio's security features are clearly a great addition to the arsenal when it comes to securing cloud native applications. We mustn't, however, be seduced into thinking that it's a silver bullet that will allow us to be less strict in our observance of security principles, such us 'defense in depth' and 'least privilege'. In fact, if an attacker can compromise the control plane, or evade the attention of the proxies in the data plane, then the mesh of services suddenly becomes very vulnerable... especially if we rely solely on Istio to protect those services.


With that in mind, it's essential that care is taken when deploying and configuring Istio to manage application services. Don't run services as the root user if it can be avoided, and if it can't be avoided, take action to limit the power available to processes running inside a pod's containers.
Make good use of the inherent security features of Kubernetes (Pod Security Polices and Network Policies) to mitigate the risk of compromise to Istio itself, and to any other infrastructure components that live outside the control of the mesh. It pays to configure layers of security that provide defence in depth.


Conclusion

Istio is a relatively new approach to managing the complexity that the ephemeral, distributed, nature of cloud native applications introduces. At this juncture, some may question the maturity of the approach, and certainly the features and codebase, but in time Istio and tools like it, certainly have the potential to make a significant contribution to the security of the cloud native stack.
Coupled with more advanced tooling that can aggregate security for services in and out of the mesh using intelligent techniques, the management of threats can be significantly simplified.
If you're already embarked on a cloud native transformation within your organization, be sure to check the progress of the Istio project as it develops within the community.

 

Save your spot: Using Istio to Securely Monitor your Services. 

Or contact us today to learn more.

 

Topics: cloud security, kubernetes, containers, microservices, devops, Istio