• Apr 26, 2019
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’s security features involve multiple components:
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.
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:
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”.
Istio’s security configurations, automated toolchains and security architecture gives significant benefits:
This guest post was written by Nitzan Niv, Head of Security Research at Alcide
Giant Swarm’s managed microservices infrastructure enables enterprises to run agile, resilient, distributed systems at scale, while removing the tasks related to managing the complex underlying infrastructure.
GET IN TOUCH
CERTIFIED SERVICE PROVIDER