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

Whenever there is a connection, it is bound to bring security problems, such as human society, and the same is true of serving the grid world.

Today, let's talk about the second main function of Istio-protection service.

In that case, three questions arise:

L Istio on what basis to protect the service?

How does Istio protect the service exactly?

How to tell Istio to exert protection ability?

1 Istio on what basis to protect the service?

Decomposing individual applications into services brings many benefits to the development and maintenance of large software systems, such as better flexibility, scalability and reusability. But it also raises some security issues:

In order to resist man-in-the-middle attacks, traffic needs to be encrypted.

In order to provide flexible service access control, mTLS (two-way secure transport layer protocol) and fine-grained access policy are needed.

L audit tools are needed to audit who did what and when

Istio attempts to provide a comprehensive security solution to solve these three problems.

As shown in the above figure

The three main goals of Istio security are:

Default security (Security by default): application code and infrastructure, no need to change.

Defense in depth (Defense in depth): integrates with existing security systems to provide multiple layers of defense.

Zero trust network (Zero-trust network): build a security solution on an untrusted network.

In order to achieve these three goals, Istio security features provide four major daemon systems:

L powerful identity (Identity) system

L robust policy (Policy) system

Authentication, authorization and audit (AAA: Authentication, Authorization, Accounting) system for protecting services and data

L transparent TLS encryption (Encryption) system.

In terms of protected objects, Istio security systems can resist internal or external threats, which are mainly targeted at endpoints (Endpoints), communications (Communication), platforms (Platform) and data (Data) within the service grid.

2 how does Istio protect the service?

In terms of security, Istio has three ambitious goals and four guardian systems, so what kind of architecture does it use to achieve this goal, and what kind of security infrastructure does it use to cooperate with kubernetes?

2.1 Istio security architecture

As shown in the figure above, corresponding to the four major daemon systems of Istio, the components involved in security in Istio are:

L Pilot: distribute authorization policy and security naming information to agents

L Proxy: implement secure communication between client and server

L Citadel: for key and certificate management

L Mixer: manage authorization and audit

Thus it can be seen that Pilot is not only responsible for the distribution of traffic rules and policies, but also responsible for the distribution of security-related policies, a bit like the emperor's personal eunuch, responsible for reading the edict; Proxy is a bit like the state officials of each state, responsible for carrying the sky; Citadel is a bit like the seal and Tiger Fu, responsible for verifying the truth and removing the fake; Mixer is a bit like three provinces and six departments, responsible for authorized audit.

2.2 two basic security concepts 2.2.1 Identity

Identity (Identity) is a basic concept in almost all security infrastructure. Before the service and service communication begins, the two parties must exchange credentials with their identity information in order to achieve the purpose of mutual authentication. On the client side, according to the secure naming (secure naming) information, check the identity of the server to see whether it is the authorized running program of the service; on the server side, according to the authorization policy (authorization policies) information, the server can determine which data the client can access, audit what it accesses at what time, and deny access to unauthorized clients.

In the Istio identity model, Istio uses a first-class service identity to determine the identity of the service. This provides great flexibility and granularity for representing human users, a single service or a group of services. On platforms that do not have such identities, Istio can use other identities that can group service instances, such as service names.

Istio service identifiers on different platforms:

L Kubernetes: Kubernetes service account

L GKE/GCE: you can use the GCP service account

L AWS: AWS IAM user / role account

L On-premises (non-Kubernetes): user account, custom service account, service name, istio service account or GCP service account.

For an analogy, both JD.com and Tmall have their own very mature service account systems. Taobao only needs to reuse Tmall's account system, and there is no need to redevelop one, so we can use Tmall's account to log in directly to Taobao. Istio also prefers to reuse industry-class service account systems, such as Kubernetes and AWS, but it is also possible to customize service accounts and reuse Kubernetes's account system on demand.

2.2.2 PKI

Istio PKI (Public Key Infrastructure) is built on top of Istio Citadel and provides secure and powerful workload identification for each workload. Istio uses X.509 certificates to carry identity information in SPIFFE format. PKI can also rotate keys and certificates automatically on a large scale.

Istio supports services that run on Kubernetes pod and local computers. Currently, Istio uses a different certificate key configuration mechanism for each scheme. Here is an example of the configuration process of Kubernetes scheme:

1. Citadel monitors Kubernetes apiserver, creating SPIFFE certificates and key pairs for each existing and new service account. Citadel stores certificates and key pairs as Kubernetes secrets.

two。 When you create a pod, Kubernetes mounts the certificate and key pair to the pod through Kubernetes secret volume based on its service account.

3. Citadel monitors the life cycle of each certificate and automatically rotates the certificate by rewriting the Kubernetes secret.

4. Pilot generates secure naming information that defines which service accounts can run a service. Pilot then passes the secure naming information to Envoy.

3 how to tell Istio to give full play to its protection ability?

As mentioned in the previous chapter, based on the control plane component, Istio introduces a first-class service account system, combined with powerful PKI, to achieve the security guard of the service grid. At the same time, Istio also opens the interface, so that we can carry out fine configuration to meet our security needs for services in all aspects.

Service security is always inseparable from two specific processes: Authentication and Authorization. Istio defines authentication-related functions through Policy and MeshPolicy files, and enables and defines authentication-related functions through RbacConfig, ServiceRole and ServiceRoleBinding files.

Let's give a few popular examples to distinguish between authentication and authentication:

To enter the railway station, you need to provide ID card and train ticket, ID card can prove that you are you, this is authentication; train ticket can prove that you have the right to get on that train, this is authorization.

For example, if you want to visit your Taobao shopping cart, you need to log in first. This is authentication. If you want to access your friend's shopping cart, you need his permission. This is authorization.

For example, experienced friends can find that browsers often face two error codes: 401 and 403. Generally speaking, 401 means not logged in and requires authentication; 403 means forbidden access and requires authorization.

3.1 Certification

Istio provides two types of authentication:

L Transport authentication, also known as service-to-service authentication: authenticates directly connected clients. Istio provides two-way TLS as a full-stack solution for transport authentication. We can easily enable this feature without changing the service code. This solution:

L provides strong identity for each service for cross-cluster and cross-cloud interoperability.

L protects service-to-service communication and end-user-to-service communication.

L provides a key management system to automate key and certificate generation, distribution and rotation.

L Source authentication, also known as end user authentication: authenticates the original client request from the end user or device. Istio simplifies the work of developers and makes it easy to achieve request-level authentication through JSON Web Token (JWT), Auth0, Firebase Auth, Google Auth, and custom authentication.

In both cases, Istio stores the authentication policy in the Istio configuration store (Istio config store) through a custom Kubernetes API. Pilot synchronizes when appropriate, updating the latest status and key for each Proxy. In addition, Istio supports authentication in the licensing model to help us understand how the security state of the service changes before and after the policy change.

3.1.1 Certification Architecture

We can use authentication policies to specify authentication requirements for services that receive requests in the Istio grid. We use the .yaml file to configure the policy, which is saved in the Istio configuration store. After any policy changes, Pilot converts the new policy into the appropriate configuration and sends it to Envoy to tell it how to implement the required authentication mechanism. Pilot can obtain the public key and attach it to JWT for configuration verification. Alternatively, Pilot provides the path to the keys and certificates managed by the Istio system and installs them into the payload Pod for two-way TLS.

This article mentions two-way TLS authentication many times, so let's understand its implementation in Istio. Istio communicates through the Envoy provided by the client and the server, that is, the traffic of the client and the server is taken over by their respective Envoy. For the client to invoke the server, the steps to follow are:

1. Istio reroutes outbound traffic from the client to the client's local Envoy.

two。 The client Envoy starts a two-way TLS handshake with the server Envoy. During the handshake, the client Envoy also performs a security naming check to verify that the service account provided in the service certificate is authorized to run the target service.

3. The client Envoy and the server Envoy establish a two-way TLS connection, and the Istio forwards the traffic from the client Envoy to the server Envoy.

4. After authorization, the server Envoy forwards the traffic to the server service through the local TCP connection.

3.1.2 Authentication policy configuration

As with other Istio configurations, authentication policies can be written in the form of .yaml files and then deployed using Istioctl binary tools. In the configuration shown in the figure below, by configuring the Policy file, the reviews service is configured for transport authentication, requiring it to use two-way TLS for authentication.

ApiVersion: "authentication.Istio.io/v1alpha1"

Kind: "Policy"

Metadata:

Name: "reviews"

Spec:

Targets:

-name: reviews

Peers:

-mtls: {}

3.2 authorization

Istio's authorization function, also known as role-based access control (RBAC), provides namespace-level, service-level, and method-level access control for services in the Istio services grid. It is characterized by:

L is based on role semantics and is easy to use.

L includes service-to-service and end-user-to-service authorization modes.

L flexibly customize authorization policies through custom properties, such as conditions, roles and role bindings.

L high performance because the Istio authorization function is performed in Envoy.

3.2.1 Authorization Architecture

The figure above shows the basic Istio authorization architecture. As with the authentication process, the operator uses the .yaml file to specify the Istio authorization policy. After deployment, Istio saves the policy in Istio Config Store. Pilot monitors Istio authorization policy changes all the time, and if it finds any changes, it obtains the updated authorization policy and distributes the Istio authorization policy to Envoy agents in the same pod as the service instance.

Each Envoy agent runs an authorization engine that authorizes requests at run time. When the request arrives at the agent, the authorization engine evaluates the request context according to the current authorization policy and returns the authorization result ALLOW or DENY.

3.2.2 Authorization Policy configuration

We can use RbacConfig to enable authorization policy and use ServiceRole and ServiceRoleBinding to configure authorization policy.

RbacConfig is a singleton of a grid dimension with a fixed name value of default, which means that we can only configure one RbacConfig instance in the grid. Like other Istio configuration objects, RbacConfig is defined as a Kubernetes CustomResourceDefinition (CRD) object.

In RbacConfig, the operator can specify a mode value, which can be:

L OFF: disable Istio authorization.

L ON: Istio authorization is enabled for all services in the grid.

L ON_WITH_INCLUSION: enable Istio authorization only for the services and namespaces specified in the containing field.

L ON_WITH_EXCLUSION: Istio authorization is enabled for all services in the grid except for the services and namespaces specified in the fields.

In the following example, Istio authorization is enabled for the default namespace.

ApiVersion: "rbac.Istio.io/v1alpha1"

Kind: RbacConfig

Metadata:

Name: default

Namespace: Istio-system

Spec:

Mode: 'ON_WITH_INCLUSION'

Inclusion:

Namespaces: ["default"]

After enabling authorization for the service and namespace, we also need to configure a specific authorization policy, which is achieved by configuring ServiceRole and ServiceRoleBinding. Like other Istio configuration objects, they are also defined as CRD objects.

ServiceRole defines a set of permissions to access the service. ServiceRoleBinding grants ServiceRole to specific objects, such as users, groups, or services.

The combination of ServiceRole and ServiceRoleBinding specifies who is allowed to do what under what conditions, specifically:

L who refers to the subject part of ServiceRoleBinding.

What to do refers to the rule part of ServiceRole.

Which conditions mean that we can use the condition part specified by Istio Attributes in ServiceRole or ServiceRoleBinding.

Let's take another simple example. As shown in the figure below, the configuration of ServiceRole and ServiceRoleBinding stipulates that all users (user= "*") are bound to the (products-viewer) role, which can initiate GET or HEAD requests to the products service, but the restriction is that the request header must contain version and the value is v1 or v2.

ApiVersion: "rbac.Istio.io/v1alpha1"

Kind: ServiceRole

Metadata:

Name: products-viewer

Namespace: default

Spec:

Rules:

-services: ["products"]

Methods: ["GET", "HEAD"]

Constraints:

-key: request.headers [version]

Values: ["v1", "v2"]

-

ApiVersion: "rbac.Istio.io/v1alpha1"

Kind: ServiceRoleBinding

Metadata:

Name: binding-products-allusers

Namespace: default

Spec:

Subjects:

-user: "*"

RoleRef:

Kind: ServiceRole

Name: "products-viewer"

So far, let's make a simple summary: when a single application is split into hundreds of services, it brings security problems. Istio tries to add a full-stack solution to the service grid composed of services. In this solution, Istio silently deals with most of the security infrastructure, but it also exposes authentication and authorization functions that allow users to customize the configuration. We can configure all the functions of the authentication and authorization link through Policy, MeshPolicy, RbacConfig, ServiceRole and ServiceRoleBinding without intrusively changing the code of any service.

Https://www.huaweicloud.com/product/cce.html

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.