Why does istio use spirit for identity authentication?

This year, 6 At the beginning of ,Istio 1.14 Release  ^[1] , The most noteworthy feature in this release is the addition of a pair of SPIRE Support for .SPIFFE^[2]  and SPIRE All are CNCF Incubation projects , among SPIRE yes SPIFFE One of the implementations of . This article will show you about SPIRE The meaning of zero trust Architecture , as well as Istio Is why you use SPIRE Implement identity authentication .

Kubernetes Authentication in

We all know Istio Originally based on Kubernetes Built up , Talking about Istio Use in SPIRE Before authentication , So let's see Kubernetes How to do identity authentication in .

Let's take a look at one pod Of token Example , Here is default Under the namespace sleep pod Of Service Account Of token.

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  Field , If this token Be stolen , What are the consequences ？Kubernetes Use in Service Account To manage Pod The identity of the , And then use it RBAC Specify a Service Account Of Pod Yes Kubernetes API Authority .Service Account Of token Stored in Secret in ,token Does not contain the nodes on which the workload is running 、pod Statement of , once token The person who is stolen and destroyed has all the permissions of the account , Pretend to be the user to steal information or destroy .

One token Load identities can only be marked in one cluster ,Istio Support at the same time Kubernetes Environment and virtual machines , There are also multiple clusters and multiple grids , How to unify workload identities in these heterogeneous environments ？ At this time , A unified workload identity standard is just around the corner .

SPIFFE And SPIRE brief introduction

SPIFFE Is based on the concept of zero trust , Build an open 、 Unified workload identity standards , This helps to build a fully authenticated data center network with zero trust .SPIFFE The core of is through simple API Defines a short-term encrypted identity file SVID, Used as identity file for workload Authentication , For example, establish TLS Connect or sign and verify JWT Token, etc .SPIRE It can rotate automatically according to the policy defined by the administrator X.509 SVID Certificates and secret keys .Istio Can pass SPIRE Dynamic consumer workload identification ,SPIRE Workload identification can be provided dynamically .

Now I will give you a brief introduction to SPIFFE Some related terms .

• • SPIFFE（Secure Production Identity Framework For Everyone） Is a set of identity authentication standards .

• • SPIRE（SPIFFE Runtime Environment） yes SPIFFE A standard set of production ready implementations .

• • SVID（SPIFFE Verifiable Identity Document） Is the document that the workload certifies its identity to a resource or caller .SVID Contains a SPIFFE ID, Represents the identity of the service . It will SPIFFE ID Encoded in a file that can be encrypted and verified , Two formats are currently supported ：X.509 Certificate or JWT token .

• • SPIFFE ID  Is a uniform resource identifier （URI）, The format is as follows ：spiffe://trust_domain/workload_identifier.

SPIRE contain Server and Agent Two parts , Their functions are as follows .

SPIRE Server

• •  Identity mapping

• •  Node authentication

• • SVID Issued by

SPIRE Agent

• •  Workload certification

• •  Provide 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 The solution is to identify the workload .

In the age of virtual machines, we may be based on a IP Address and port to identify a workload , be based on IP Address identification: multiple services share one IP Address ,IP Address forgery and too large access control list . here we are Kubernetes Time , The life cycle of a container is short , We can no longer IP Address to identify the load , But through pod or service name . however , Different clouds 、 Software platforms have different ways of identifying workloads , There are compatibility problems with each other . Especially in heterogeneous hybrid clouds , There are both virtual machine and container workloads . At this time , Build a fine-grained 、 An interoperable identification system , Will be of great significance .

stay Istio Use in SPIRE Do identity authentication

Istio Make use of SPIRE Provide a unique identifier for each workload , The workload in the service grid is performing peer-to-peer authentication 、 Both request authentication and authorization policies will use the service identity , Used to verify whether access is allowed .SPIRE Native support Envoy SDS API,SPIRE Agent The pass in is shared with that in the workload UNIX Domain Socket signal communication , Issue... For the workload SVID. Please refer to  Istio file  ^[3]  Learn how to be in Istio Use in SPIRE Do identity authentication .

SDS The most important benefit is simplified certificate management . Without this feature , stay Kubernetes deployment in , The certificate must be in the form of secret The way is created , Then mount into the proxy container . If the certificate expires , It needs to be updated secret And the proxy container needs to be redeployed . If you use SDS,Istio have access to SDS The server will push the certificate to all Envoy example . If the certificate expires , The server only needs to push the new certificate to Envoy example ,Envoy The new certificate will be used immediately without redeploying the agent container .

The following figure shows Istio Use in SPIRE An architecture for identity authentication .

Istio Use in SPIRE The architecture of identity authentication

stay Kubernetes In the cluster  spire  Use... In the namespace StatefulSet Deploy SPIRE Server and Kubernetes Workload Registrar, Use DaemonSet Resources deploy one for each node SPIRE Agent. Suppose you are installing Kubernetes The default is used when DNS name  cluster.local,Kubernetes Workload Registar^[4]  Would be Istio Mesh The workload in creates an identity in the following format ：

• • 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}

In this way, both nodes and each workload have their globally unique identity , It can also be based on the cluster （ Trust domain ） Expand .

Istio Mesh The workload authentication process in is shown in the following figure .

Istio Schematic diagram of workload authentication process in service grid

The detailed process is as follows ：

1. 1.  Workload sidecar Medium  pilot-agent  Will be shared UDS call SPIRE Agent To get SIVD

2. 2. SPIRE Agent inquiry Kubernetes（ To be exact, it is on the node kubelet） Get load information

3. 3. Kubelet Will be taken from API server The queried information is returned to the workload validator

4. 4.  The verifier will kubelet The result of the return and sidecar Shared identity information comparison , If the same , Will be correct SVID The cache is returned to the workload

For the detailed process of workload registration and certification, please refer to  SPIRE file  ^[5] .

summary

Identity is the foundation of a zero trust network ,SPIFFE Unified identity standards in heterogeneous environments . stay Istio Whether we use or not SPIRE, Authentication is not perceived by the workload . adopt SPIRE To provide authentication for the workload , The identity of the workload can be effectively managed , Lay a good foundation for the realization of zero trust network .

Reference link

[1] Istio 1.14 Release : https://istio.io/latest/news/releases/1.14.x/announcing-1.14/
[2] SPIFFE: https://spiffe.io/
[3] Istio file : https://istio.io/latest/docs/ops/integrations/spire
[4] Kubernetes Workload Registar: https://github.com/spiffe/spire/blob/main/support/k8s/k8s-workload-registrar/README.md
[5] SPIRE file : https://lib.jimmysong.io/kubernetes-handbook/concepts/spire/

More cloud native community information , Join the cloud native community discussion group , welcome Join the cloud native community , Click to read the original to learn more .