Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to deeply analyze the security module in Istio. Many people may not know much about it. In order to let you know more, Xiaobian summarizes the following contents for you. I hope you can gain something according to this article.

After a single application is split into microservices, a series of benefits such as improving development efficiency, increasing system stability, and improving operation and maintenance efficiency are also brought, but security risks are also brought along. Previously, local calls are all changed to network protocol call interfaces. Today, we will focus on the analysis of security modules in Istio, the upstart in microservices architecture. Istio has three security goals:

Security by default: Application code and infrastructure do not need to be changed.

Defense in depth: Integrate with existing security systems to provide multiple layers of defense.

Zero-trust network: Building security solutions on untrusted networks.

architecture

As shown above, Istio security involves components:

Citadel is used for key and certificate management.

Proxy enables secure communication between client and server.

Pilot distributes authorization policies and security naming information to agents.

Mixer: Verify authorization and audit.

Istio Identity

identity information

Identity information is the basic concept of security infrastructure. Before the communication between services starts, both parties must exchange credentials with their identity information to achieve the purpose of mutual authentication. According to the security information, the purpose of authentication can be achieved. At the same time, according to the identity information, audit can be carried out. In the environment of kubernetes, Istio identity uses Service Account.

PKI

PKI (Public Key Infrastructure) is built on top of Istio citadel, which uses X.509 certificates to carry identity information in SPIFFE format. PKI can also automate key and certificate rotation on a large scale.

Certificate generation process

The certificate generation process based on kubernetes environment is as follows:

Citadel also listens to the lifecycle of each certificate and automatically rotates certificates by rewriting Kubernetes secret. Pilot generates security information, that is, authorization information. Pilot distributes authorization information to envoy. Each namespace has a default serviceaccount. Citadel creates a secret named istio.default for it.

[root@kube01 ~]$ kubectl -n foo get secrets NAME TYPE DATA AGE default-token-bdpmg kubernetes.io/service-account-token 3 8d istio.default istio.io/key-and-cert 3 8d

By default, istio apps created in this namespace use this secret.

istio-certs: Type: Secret (a volume populated by a Secret) SecretName: istio.default Optional: true

When a non-default serviceaccount is specified for a deployment, the new secret is used for the secret.

istio-certs: Type: Secret (a volume populated by a Secret) SecretName: istio.bookinfo-productpage Optional: true authentication

Istio provides two types of authentication:

Transport authentication, also known as service-to-service authentication: authenticates direct clients to make connections. Istio offers mutual TLS as a complete stack solution for transport authentication.

Source authentication, also known as end-user authentication: authenticates the original client that will request as the end-user or device.

For details, see the official website. This article mainly introduces the first one.

Mutual TLS Authentication (mTLS)

The mTLS process itself is shown below:

During the Istio handshake, the client envoy also performs a security naming check to verify that the service account provided in the server certificate has permission to run the target service.

authentication architecture

Configure authentication policies through yaml files. After deployment, the policies are stored in the Istio configuration store. Pilot listens to the configuration store. When changes occur, Pilot converts the policies into appropriate configurations (configurations recognized by envoy, etc.), and then notifies envoy how to implement the authentication mechanism. Pilot provides the path of keys and certificates managed by Istio system, and installs them into the application mesh for mutual TLS. Istio sends the configuration asynchronously to the target endpoint, and when the proxy receives the message, the new authentication takes effect immediately.

The certification architecture is shown below:

Deployment impact

When deploying the Istio platform, istio-demo-auth.yaml is installed through yaml, which adds tls related information to all envoy in the control panel, and global.controlPlaneSecuretyEnable: true in the helm. After opening, it is essentially controlPlaneAuthPolicy: MUTUAL_TLS. The changes after adding this attribute are analyzed as follows:

control panel

Istio-policy,istio-telemetry,istio-pilot, three components in istio-proxy envoy process will specify configuration files, in turn envoy_policy.yaml,envoy_telemetry.yaml,envoy_pilot.yaml, in these files the same are added as follows:

"tls_context": { "common_tls_context": { "alpn_protocols": "h3", "tls_certificates": { "certificate_chain": { "filename": "/etc/certs/cert-chain.pem" }, "private_key": { "filename": "/etc/certs/key.pem" } }, "validation_context": { "trusted_ca": { "filename": "/etc/certs/root-cert.pem" }, "verify_subject_alt_name": [ "spiffe://cluster.local/ns/istio-system/sa/istio-pilot-service-account" ] } }

Determine the value of controlPlaneAuthPolicy in the template file address. If this value is set to None, after the grid policy mtls is enabled, each component of the control panel does not support tls, resulting in forwarding failure. You must set the target rule mode of the control panel to DISABLE, otherwise the handshake will fail, and error 503 will be reported, as shown below:

[2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/network/connection_impl.cc:466] [C127] connected [2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:113] [C127] handshake error: 2 [2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/ssl/ssl_socket.cc:113] [C127] handshake error: 5 [2018-10-23 02:55:45.510][19][debug][connection] external/envoy/source/common/network/connection_impl.cc:133] [C127] closing socket: 0

data panel

This value in the data panel controlPlaneAuthPolicy: None does not affect the use of mtls function (please contact to change if there is an error).

authentication policy

Istio can store authentication policies in namespace scope or grid scope. Use the official website instance sleep to access httpbin for testing. The access process is shown in the following figure:

Example of deploying official website, Step 1:

$ kubectl create ns foo $ kubectl apply -f

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.