In early June this year,Istio 1.14 was released
, the most noteworthy feature in this release is the new support for SPIRE. SPIFFE
Both SPIRE and SPIRE are CNCF incubation projects, of which SPIRE is one of the implementations of SPIFFE. This article will walk you through what SPIRE means for a zero trust architecture, and why Istio uses SPIRE for authentication.
Authentication in Kubernetes
We all know that Istio was originally built based on Kubernetes. Before talking about using SPIRE for identity authentication in Istio, let’s take a look at how identity authentication is done in Kubernetes.
Let’s look at an example of a pod’s token. The following is the token of the Service Account of the sleep pod in the default namespace.
apiVersion: v1 data: ca.crt: { CA_CRT } namespace: ZGVmYXVsdA == token: { TOKEN_STRING } kind: Secret metadata: annotations: kubernetes.io/service-account.name: sleep kubernetes.io/service-account.uid: 2c0d00e8-13a2-48d0-9ff8-f987f3325ecf creationTimestamp: "2022-06-14T03:01:35Z" name: sleep-token-gwhwd namespace: default resourceVersion: "244535398" uid: b8822ceb-9553-4a17-96dc-d525bbaed0e0 type: kubernetes.io/service-account-token
We see that there are ca.crt and token fields. If this token is stolen, what will be the consequences? In Kubernetes, Service Account is used to manage the identity of the Pod, and then RBAC is used to specify the permissions of the Pod with a Service Account to the Kubernetes API. The token of the Service Account is stored in the Secret. The token does not contain the statement of the nodes and pods that the workload runs on. Once the token is stolen, the destroyer obtains all the permissions of the account, disguised as the user to steal information or destroy.
A token can only mark workload identities in one cluster. Istio supports both Kubernetes environments and virtual machines, as well as multiple clusters and multiple grids. How to unify workload identities in these heterogeneous environments? At this point, a unified workload identity standard is on the horizon.
Introduction to SPIFFE and SPIRE
The purpose of SPIFFE is to establish an open and unified workload identity standard based on the concept of zero trust, which will help to build a zero trust fully identifiable data center network. The core of SPIFFE is to define a short-lived encrypted identity file SVID through a simple API, which is used as an identity file for workload authentication, such as establishing TLS connections or signing and validating JWT tokens. SPIRE can automatically rotate X.509 SVID certificates and keys according to administrator-defined policies. Istio can dynamically consume workload identifiers through SPIRE, and SPIRE can dynamically provide workload identifiers.
Below I will briefly introduce some terms related to SPIFFE for you.
- SPIFFE (Secure Production Identity Framework For Everyone) is a set of authentication standards.
- SPIRE (SPIFFE Runtime Environment) is a set of production-ready implementations of the SPIFFE standard.
- A SVID (SPIFFE Verifiable Identity Document) is a document that a workload uses to prove its identity to a resource or caller. The SVID contains a SPIFFE ID, which represents the identity of the service. It encodes the SPIFFE ID in a cryptographically verifiable file and currently supports two formats: X.509 certificate or JWT token.
- SPIFFE ID is a Uniform Resource Identifier (URI) in the following format:
spiffe://trust_domain/workload_identifier.
SPIRE includes two parts, Server and Agent, and their functions are as follows.
SPIRE Server
- Identity Mapping
- Node authentication
- SVID issued
SPIRE Agent
- Workload Certification
- Provides a workload API
SPIFFE and Zero Trust Security
The essence of zero trust is identity-centric dynamic access control. Dynamic certificate rotation, dynamic certificate issuance, dynamic permission control. SPIFFE addresses the problem of identifying workloads.
In the era of virtual machines, we may identify a workload based on an IP address and port. Based on IP address identification, there are problems such as multiple services sharing an IP address, IP address forgery, and access control lists being too large. In the era of Kubernetes, the lifecycle of containers is short-lived, and we can no longer identify loads by IP addresses, but by pod or service names. However, different clouds and software platforms have different methods for identifying workloads, and there are compatibility issues between them. Especially in a heterogeneous hybrid cloud, there are workloads of both virtual machines and containers. At this time, it is of great significance to establish a fine-grained, interoperable identification system.
Authentication with SPIRE in Istio
Istio will use SPIRE to provide a unique identifier for each workload, and the workloads in the service mesh will use the service identifier for peer authentication, request authentication, and authorization policies to verify whether access is allowed. SPIRE natively supports the Envoy SDS API, and the SPIRE Agent issues SVIDs for workloads by communicating with UNIX Domain Sockets shared among the workloads. Please refer to the Istio documentation
Learn how to use SPIRE for authentication in Istio.
The most important benefit of SDS is simplified certificate management. Without this feature, in Kubernetes deployments, certificates would have to be created as secrets and then mounted into the proxy container. If the certificate expires, the secret needs to be updated and the proxy container needs to be redeployed. If using SDS, Istio can use the SDS server to push the certificate to all Envoy instances. If the certificate expires, the server just needs to push the new certificate to the Envoy instance, and Envoy will use the new certificate immediately without redeploying the proxy container.
The following diagram shows the architecture of authentication using SPIRE in Istio.
Architecture diagram of using SPIRE for authentication in Istio
Deploy SPIRE Server and Kubernetes Workload Registrar using StatefulSet in the spire namespace in the Kubernetes cluster, and deploy a SPIRE Agent per node using the DaemonSet resource. Assuming you installed Kubernetes with the default DNS name cluster.local , Kubernetes Workload Registar
An identity in the following format is created for workloads in Istio Mesh:
- SPRRE Server:
spiffe://cluster.local/ns/spire/sa/server - SPIRE Agent:
spiffe://cluster.local/ns/spire/sa/spire-agent - Kubernetes Node:
spiffe://cluster.local/k8s-workload-registrar/demo-cluster/node/ - Kubernetes Worload Pod:
spiffe://cluster.local/{namespace}/spire/sa/{service_acount}
This allows both nodes and each workload to have their globally unique identities, and can also scale according to the cluster (trust domain).
The workload authentication process in Istio Mesh is shown in the following diagram.
Diagram of the workload authentication process in an Istio service mesh
The detailed process is as follows:
- The
pilot-agentin the sidecar of the workload will call the SPIRE Agent through the shared UDS to obtain the SIVD - SPIRE Agent asks Kubernetes (to be precise, the kubelet on the node) for load information
- The kubelet returns the information queried from the API server to the workload validator
- The validator compares the result returned by the kubelet with the identity information shared by the sidecar, and if they are the same, returns the correct SVID cache to the workload
Please refer to the SPIRE documentation for the detailed process of registering and authenticating workloads
.
Summarize
Identity is the foundation of zero-trust networking, and SPIFFE unifies identity standards in heterogeneous environments. In Istio, authentication is workload-agnostic whether we use SPIRE or not. Using SPIRE to provide authentication for workloads can effectively manage the identities of workloads and lay a solid foundation for the realization of zero-trust networks.
This article is reprinted from https://jimmysong.io/blog/why-istio-need-spire/
This site is for inclusion only, and the copyright belongs to the original author.