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

This article is mainly to give you a brief introduction to the realization of Istio13:Istio basic certification. You can check the relevant professional terms on the Internet or find some related books to supplement them. We will not dabble here. Let's go straight to the topic of realizing Istio13:Istio basic certification. I hope it can bring you some practical help.

Preface

Micro-service architecture provides better flexibility, scalability and the ability to reuse services. However, micro-services also have special security requirements, and Istio Security tries to provide comprehensive security solutions. In order to provide flexible service access control, two-way TLS and fine-grained access policies are needed. Istio provides two types of authentication: transport authentication and source authentication. By configuring different levels of authentication policies, you can quickly control different security access granularities.

Typical usage scenarios:

1. In Kubernetes clusters with Istio installed without bi-directional TLS enabled, full-grid bi-directional TLS needs to be enabled quickly.

two。 Bidirectional TLS is required between some services within the grid. You can put these services in the same namespace and enable bidirectional TLS in the namespace.

3. When a single service needs to enable TLS, it can be specified through the spec field in the configuration policy

The authentication policy takes effect on the requests received by the service. To specify the client authentication policy in the two-way TLS, you need to set the TLSSettings in the DetinationRule, and each authentication policy needs to take effect together with the destination rule. The following is an example to demonstrate the process of configuring a transport authentication policy in different storage ranges. Source authentication is specified through the origins field in spec.

Environment preparation: install istio cluster, disable global bidirectional TLS;Httpbin application image and sleep application image

1. Create namespaces, deploy applications

Create three namespaces: httpbin and sleep applications with sidecar are deployed in foo, bar, legacy,foo and bar, and httpbin applications and sleep applications without sidecar are deployed in legacy.

Use sleep as the client and httpbin as the server to verify the accessibility of the client

two。 There is no authentication policy in the verification system.

You can see that there are no policies or rules in the foo, bar, and legacy namespaces

3. Enable two-way TLS authentication for all services in the grid

Configure the grid authentication policy:

Configure destination rules:

It should be noted that the authentication policy name within the grid must be default, and policies with other names will be rejected and ignored. Its policy type is MeshPolicy, which is different from other policy types at other levels.

These authentication policies and destination rules effectively configure all sidecars to enable the service to send and receive requests in two-way TLS mode. But it is not applicable to services without sidecar.

You can see that there are two types of connections that do not apply: a connection from a client with sidecar to a server without sidecar, and a connection from a client without sidecar to a server with sidecar.

In order to repair connections from clients with sidecar to servers without sidecar, ① can add destination rules specifically for these servers to override the TLS setting:

Retest the connection

This method can also be used to configure Kubernetes's API CVM when global two-way TLS authentication is enabled.

The only option for a ② connection from a client without sidecar to a server with sidecar (working in bi-directional TLS mode) is to switch from bi-directional TLS mode to PERMISSIVE mode, which allows the server to receive HTTP or (bidirectional) TLS traffic

The request from sleep.legacy to httpbin.foo should be successful, but the request to httpbin.bar will still fail.

Enable bi-directional TLS for all services in a namespace

You can configure a policy to enable bi-directional TLS separately for each namespace without having to enable global bidirectional TLS:

Note: policies within the scope of the namespace must be named default and do not qualify any specific services (no targets setting domain)

Add the appropriate destination rules:

Test the connection:

Since the currently configured policy and destination rules are valid only for the namespace foo, you can see that only requests from clients without sidecar (sleep.legacy) to httpbin.foo fail.

5. Enable two-way TLS for a single service

You can also set authentication policies and destination rules for a particular service. Execute the following command to add only one new policy for the httpbin.bar service.

Configure destination rules:

Enable both the namespace level and the service level

Suppose we have added a policy at the namespace level to enable bi-directional TLS for all services in the namespace foo and observe that requests from sleep.legacy to httpbin.foo have failed (see above). Now add an additional policy specifically for the httpbin service to disable bi-directional TLS (leave the peers domain blank):

You can see that the policy at the service level overrides the policy at the namespace level, and the connection is successful.

For the above about the realization of Istio13:Istio basic authentication analysis, we do not think it is very helpful. If you need to know more, please continue to follow our industry information. I'm sure you'll like it.

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.