Improving the security of Kubernetes clusters using Istio

One of the goals and benefits of using Istio as a service-mesh infrastructure is improving the security of the cluster it is embedded in and the services it contains. The security value of Istio has the following facets:

• Istio authenticates workloads’ identities and issues and manages certificates for them when creating the mesh connectivity.
• The service mesh traffic can be automatically encrypted, with mutual endpoint authentication using mTLS.
• Configurable authentication policies and secure naming information ensure traffic authorization at the transport layer.
• Fine-grained role-based access control at the application layer network protocol can be used for micro-segmentation, further enhancing users’ abilities to limit which services interact and in what ways.
• The traffic observability that Istio offers, combined with external traffic profiling and analysis tools, enables security-related traffic auditing and monitoring for detection and investigation of network behavior anomalies.

Security architecture

Istio’s security features involve multiple components:

• Citadel for key and certificate management.

• Sidecar and perimeter proxies to implement secure communication between clients and servers and to enforce policies.

• Pilot to distribute the authentication policies and secure naming information to the proxies.

• Mixer to manage authorization and auditing.

Identity, certificates, and authentication

Istio’s sidecar proxies use SPIFFE IDs to establish mTLS connections between workloads. SPIFFE is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. It provides a secure identity, in the form of a specially crafted X.509 certificate, to every workload in a modern production environment. SPIFFE removes the need for application-level authentication and complex network-level ACL configuration. SPIRE, the SPIFFE Runtime Environment, is an extensible system that implements the principles embodied in the SPIFFE standards. SPIRE manages platform and workload attestation. At the same time it provides an API for controlling attestation policies and coordinates certificate issuance and rotation.

Services in the mesh are identified and authenticated through the integration of Istio with the cluster management system. For example, with Kubernetes, the Citadel component learns about all workloads from the apiserver, and automatically issues a SPIFFE ID for each one. It stores the SPIFFE certificate and key pair it creates for each of the existing and new service accounts as Kubernetes secrets. Kubernetes mounts the certificate and key pair to the pod according to its service account via Kubernetes secret volume. Citadel also watches the lifetime of each certificate, and automatically rotates the certificates by rewriting the Kubernetes secrets.

Secure services connectivity and Authentication Policies

Istio’s secure naming information defines which service account or accounts can run a certain service. This is a mapping from the server identities, which are encoded in certificates, to the service names that are referred to by a discovery service or DNS. A mapping from identity A to service name B means “A is allowed and authorized to run service B”.

Users configure authentication requirements for services receiving requests using authentication policies. Pilot watches the Kubernetes apiserver and generates the secure naming information for the active workloads by translating the policies to instructions for the sidecar proxy. These instructions specify for each service how to perform the required authentication mechanisms of inbound requesters. Pilot distributes these authentication instructions securely to the sidecar proxies.

The sidecar proxy connects, authenticates, and establishes a mutually-authenticated TLS connection between proxied workloads. Client services are responsible for following the necessary authentication mechanism, for example by acquiring and attaching an applicative JWT credential to the request, or through a TLS certificate automatically used by the client’s proxy.

In addition to the authentication mechanism itself, the authentication policies include additional settings, like:

• Target selection: which service the policy applies to
• Scope: mesh-wide, namespace-wide or service-specific scope
• Transport authentication: mTLS
• Origin authentication: constraints on JWT usage

Applicative protocol Role Based Access Control

Micro-segmentation is a security technique that creates secure zones in cloud deployments and allows organizations to isolate workloads from one another and secure them individually. Istio’s Role-based Access Control (RBAC) provides micro-segmentation for services in an Istio mesh through namespace-level, service-level, and method-level access control for services. These controls effectively determine “who is allowed to do what under which conditions”. For example, a user can set a policy that allows service AccountAuditor to send HTTP Get requests (Read access) to path “/accounts/*” of the Payroll service while denying access to other services. The RBAC configuration is compatible with HTTP, HTTPS, HTTP2, and plain TCP.

To realize this segmentation, Istio’s Pilot watches for changes to the authorization policies and distributes these policies to the sidecar proxies that are co-located with the service instances. Each sidecar proxy runs an authorization engine that authorizes requests at runtime. When a request comes to the proxy, the authorization engine evaluates the request context against the current authorization policies, and returns the authorization result, “Allow” or “Deny”.

Conclusion

Istio’s security configurations, automated toolchains and security architecture gives significant benefits:

• Traffic in the service mesh is encrypted, between mutually authenticated endpoints, and only between services that are allowed to communicate according to the user’s configuration. These attributes prevent many types of attacks like impersonation, eavesdropping, and Man-In-The-Middle.

• Credentials creation, assignment, and distribution are handled according to best practices. Credentials are stored securely and alongside their respective workloads, so they are less likely to be compromised. Additionally, credentials are rotated frequently, so that even in the case of a compromise, the compromised credentials are of very limited use to an attacker. This setup is done automatically by Istio, without explicit coding.

• Authentication policies and RBAC provide the user with different options for allowing or blocking connectivity between services, as well as segmenting parts of the mesh according to security sensitivity and other considerations.

This guest post was written by Nitzan Niv, Head of Security Research at Alcide