Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge points of this article "what is the application scenario of Vault in Kubernetes", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "what is the application scenario of Vault in Kubernetes".

What is Vault?

How to manage and protect users' sensitive information in cloud applications is often a headache for developers. Users' passwords, certificates, keys and other private information are often placed in configuration files, code repositories or shared storage without encryption. For ordinary developers, it is a great challenge to design and implement a complete secret key management system. Regardless of the daunting encryption and decryption algorithms, many cloud applications still place some sensitive configuration information on a public configuration center just through some simple hash operations such as base64, and in many cases, this sensitive information will be leaked from a line of exception logs or monitoring alarms of the application. Moreover, for a centralized secret key management system, how to carry out more fine-grained access authentication for users is also a difficult problem.

The emergence of Vault gives a solution to the above problems. It is open source software maintained by HashiCorp (which also has well-known products such as Vagrant,Terraform,Consul). Its design idea is based on the characteristics of dynamic infrastructure under the native background of the cloud. It is difficult to find traditional trust boundaries between different network layers and different services on the cloud. Authentication and access control with identity as the core are emphasized between services. Instead of using IP and host address as trust credentials, as in traditional static infrastructure. For this reason, Vault provides the following function points:

The diversity of Secret storage forms, any kv form of sensitive information (such as database passwords, certificates, ssh login keys, openapi credentials, etc.)

The diversity of storage formats, support plug-in storage engine expansion, can be docked with a variety of plug-in engines such as AWS,Consul,NoSQL,KV,PKI,SSH

Support authentication docking with various platforms, and dynamically generate authentication credentials or configuration information

Support private key segmentation based on Shamir algorithm to complete the sealing and unsealing operation of Vault backend, and also support highly available deployment forms.

Support dynamic generation, renewal, revocation and rolling update of all kinds of secret

Complete audit log

Complete CLI and RESTful API

Integration of Vault and K8s

Vault's loosely coupled architecture enables it to interface with a variety of secret engines and corresponding storage backends, and to support interaction with a variety of authentication servers.

In this section, we focus on the integration of Vault and k8s.

Application scenario of Vault in Kubernetes

As an enterprise-level secret management tool, Vault is a strong security demand for some large customers in the business cloud process, especially in foreign markets. There are mainly the following application scenarios in Kubernetes clusters:

As an application deployed in a Kubernetes cluster, it provides key management services, supports interfacing with multiple mainstream cloud vendors and multiple secrets forms, supports storage interfacing with multiple database services, and supports interfacing with multiple forms of authentication.

As a public encryption service (Encryption as a Service) without docking the back-end storage, it helps user applications strip off the tedious encryption and decryption logic.

For government, financial and other customers who have high requirements for data security specifications, Vault supports the use of private key segmentation algorithm to unpack back-end services based on Two-man principles, and provides enterprises with more secure and reliable secret management capabilities combined with the highly available deployment form of K8s.

Of course, this is only a list of some Vault native capabilities, as a security application that runs directly on the Kubernetes cluster, any K8s-oriented application can take advantage of its security capabilities.

Install Vault

Vault supports helm installation, and we can find detailed configuration instructions on startup parameters in its official documentation. At the same time, we can also easily install Vault in the ACK cluster through the console in the application directory apphub of Ali Cloud CCS.

In addition, the default installation of Vault also integrates the installation of its console. We can access its UI on the public network through load balancer service or ingress routing. We can find the root token used for login in the vault pod log, and you can easily configure the interface with the storage engine and authentication method in the console. At the same time, you can also configure policy-based access control.

Integration of authentication methods

When a user wants to communicate with the Vault server in the business logic of K8s pod to obtain the required secrets, Vault will first authenticate the request in the pod, so how should the Vault request authentication credential in this pod be obtained? As mentioned above, the Vault backend supports the docking of multiple authentication methods, and for Kubernetes,Vault, it supports authentication based on K8s Service Account Token.

In use, the Vault administrator first needs to generate a specified sa that interacts with Vault in the back-end enable kubernetes authentication method, and then writes sa token, cluster ca, public network address and other information to the Vault backend through CLI or API, and configures the ACL policy binding with the vault backend. Please refer to the official documentation for detailed steps.

Of course, pod applications can not be limited to the use of sa-based kubernetes authentication. For example, [kubernetes-vault] (https://github.com/Boostport/kubernetes-vault)

). The project uses [AppRole] (https://www.vaultproject.io/docs/auth/approle.html) in Vault

) authentication. In this authentication mode, administrators can create different Vault native role models for different pod and bind them to the corresponding policy. At the same time, they can create token corresponding to secret_id,secret_id based on role, which can be used as temporary credentials for authentication with Vault. Kubernetes-vault uses the authentication interaction mode of AppRole. The kubernetes-vault controller that has been installed first will go to create all the pod in the Watch cluster. When it is found that the init-container of the specified annotation exists in the deployment template of the new pod, the controller will obtain the corresponding secret_id according to the vault role id to Vault request specified in the template and send it to the client of the kubernetes-vault in the init-container. Before the application container starts, the kubernetes-vault client uses the secret_id and role_id returned by controller to Vault the real login token and finally writes it to the mount directory shared with the application pod At the same time, the client will rotate regularly according to the expiration time of token to ensure its availability.

There are also many other schemes for authentication docking with Vault based on K8s in the community, and their design ideas are more or less the same, basically using init-container or sidecar to introduce an additional client to Vault to request short-term credentials under the specified authentication mode and share them with the business container.

We can also find kubernetes-vault in the application directory apphub in the CCS console, which makes it easy for developers to use helm to directly deploy namespaces in the cluster. Vault also plans to add configuration items in subsequent official versions of helm chart to support the dynamic injection of the above login authentication secret.

Integration of Vault and Aliyun RAM

When we need to access Ali Cloud resources in the application, we need to use the AK or STS temporary credentials corresponding to the RAM account as the credential to access the corresponding resource interface. If you use account AK, how to ensure the security of AK while it can be obtained by application logic has always been a headache; if you use temporary sts token, because of its timeliness, we also need to consider how to rotate temporary access credentials while considering security. Compared with the two methods, the use of sts temporary credentials is definitely a more recommended way in terms of security, and the security management of this dynamic secret is also the advantage of Vault. In this section, we will introduce the integration of Vault and Aliyun RAM in authentication method and secret management engine.

Integration of authentication methods

First of all, in the authentication mode, the role model of the Vault server can be one-to-one mapping with RAM role. Users can use the OpenAPI or CLI provided by Vault to call the GetCallerIdentity interface by passing in the temporary credentials returned by acting as RAM role. Then the Vault server will find whether there is a corresponding permission policy configuration in its backend storage according to the role returned by the request. If it exists, the authentication succeeds and an access token that can be used to call other Vault back-end interfaces is returned.

Integration of Vault Secret engine and RAM

When we need to use Ali Cloud resources in business application logic, we usually need to obtain a temporary credential returned by RAM by role-playing, and then use this temporary credential to complete the authentication process with RAM. Because of the timeliness of the certificate, we not only ensure its security, but also maintain a corresponding secret key rotation mechanism. Vault's secret engine implements an interfacing plug-in with Aliyun RAM to help us manage RAM credentials securely and dynamically. The main steps are as follows:

1. Start the back-end engine

two。 Create a dedicated sub-account for the Vault server in the RAM console and bind a customized permission policy

3. Obtain the AK corresponding to the Vault sub-account and write it to the path specified by the backend through Vault CLI/API

4. Write the policy definition or role corresponding to the RAM credential you want to obtain in the Vault backend. The policy definition supports both inline and remote policy. The so-called inline mode refers to writing the policy template directly in the api request, and the remote pattern refers to writing the policy type and name that exist in the RAM, such as:

$vault write alicloud/role/policy-based\ remote_policies='name:AliyunOSSReadOnlyAccess,type:System'\ remote_policies='name:AliyunRDSReadOnlyAccess,type:System'

The role mode requires the user to specify the role arn to be played, as well as the Vault sub-account in the trusted entity of the role. An example is as follows:

$vault write alibaba/role/role-based\ role_arn='acs:ram::5138828231865461:role/hastrustedactors'

5. In a specific business application, you only need to call the creds/policy-based or role-based API of Vault to dynamically obtain the corresponding RAM access credentials. The following is an example of a CLI call that returns temporary token by role playing:

$vault read alicloud/creds/role-basedKey Value----lease_id alicloud/creds/role-based/f3e92392-7d9c-09c8-c921-575d62fe80d9lease_duration 59m59slease_renewable falseaccess_key STS.L4aBSCSJVMuKg5U1vFDwsecret_key wyLTSmsyPGP1ohvvw8xYgB29dlGI8KMiH2pKCNZ9security_token CAESrAIIARKAAShQquMnLIlbvEcIxO6wCoqJufs8sWwieUxu45hS9AvKNEte8KRUWiJWJ6Y+YHAPgNwi7yfRecMFydL2uPOgBI7LDio0RkbYLmJfIxHM2nGBPdml7kYEOXmJp2aDhbvvwVYIyt/8iES/R6N208wQh0Pk2bu+/9dvalp6wOHF4gkFGhhTVFMuTDRhQlNDU0pWTXVLZzVVMXZGRHciBTQzMjc0KgVhbGljZTCpnJjwySk6BlJzYU1ENUJuCgExGmkKBUFsbG93Eh8KDEFjdGlvbkVxdWFscxIGQWN0aW9uGgcKBW9zczoqEj8KDlJlc291cmNlRXF1YWxzEghSZXNvdXJjZRojCiFhY3M6b3NzOio6NDMyNzQ6c2FtcGxlYm94L2FsaWNlLyo=expiration 2018-08-15T21:58:00Z how to use Vault Secret in k8s applications

After understanding the basic concepts of Vault and the authentication interaction process with Kubernetes, we move on to the topic that customers are most concerned about. How to easily get the secret managed by Vault server in k8s pod application. There are also heated discussions in the community and a number of related solutions, which are mainly focused on two directions:

* * [timing synchronization process] (https://github.com/hashicorp/vault/issues/7364

) * *: use a synchronization process to periodically obtain a specified range of key updates from the Vault server and synchronize them to the secret model in the k8s cluster, represented by vaultingkube and [secrets-manager] (https://github.com/tuenti/secrets-manager)

). Its main design idea is also different. Take secrets-manager as an example, first of all, users can define the secret data source that they follow in Vault through CRD, and then the controller corresponding to secrets-manager will regularly compare the status of k8s secret and vault secret within the specified management range in the Reconcile function, and coordinate once if they are inconsistent. In pod applications, users can directly refer to the contents of the native secret model to obtain the secret key of the remote Vault server.

Of course, there are some doubts about this secret key synchronization scheme in the community, for example, it is believed that this scheme will increase the attack surface in the transmission process of secret key synchronization and the rest interaction of user pod using native secret, but this scheme is friendly in deployment and implementation and has been supported by many users.

CSI plug-in integration: this scheme mounts the keys in Vault to pod applications in the form of volume based on CSI plugin.

Secrets-store-csi-driver can connect different vendors' back-end storage by implementing a set of driver mechanism based on CSI specification, while Vault secret's driver (secrets-store.csi.k8s.com) allows kubelet to mount secret in all kinds of enterprise key storage through volume. Once the attach action is completed, the key data is mounted to the corresponding file system of the container. On the basis of CSI driver, different secret key management backends can implement customized provider to dock with the specified interfaces in the CSI driver framework. The functions of provider are summarized as follows:

Interfacing with the back-end secret key management system, providing necessary interface implementation such as key acquisition

Adapts the interface definition of the current CSI driver

The callback function in the framework can mount the secret key data obtained from the backend to the specified path without calling Kubernetes API.

HashiCorp officials have also implemented a set of Provider for docking Vault based on this framework. Here we take this as an example to take a specific look at how to use the secret key managed in Vault through CSI plugin in a K8s pod application.

1 first we create an ACK cluster with the CSI storage plug-in enabled, and then refer to the documentation to deploy the Vault server in the cluster. To facilitate verification, we use the dev mode to omit the unseal unblocking process, and configure the authentication mode and the corresponding access control policy for the interaction between provider and Vault.

Then write test data to the Vault backend through cli

2 install Secret Store CSI Driver through the official helm method, and the command is as follows:

Helm install. -n csi-secrets-store-- namespace dev-- set providers.vault.enabled=true

After successful installation, it is shown in the following figure:

(3) create a secretproviderclasses instance in the cluster to interface the parameters of Secret Store CSI Driver and Vault. An example is as follows. Note that the vault server address can be obtained through kubectl get service vault.

4 finally, let's take a look at how to obtain the corresponding Vault key by interfacing the above provider instance in the application pod. Here, pod uses the above vault provider in two ways:

1) if the target cluster version of pod is above v1.15.0, and feature-gates of CSIInlineVolume=true is enabled for both cluster apiserver and node kubelet manifest configuration, we can declare the csi provider instance to be used in the volume field in pod.

Kind: PodapiVersion: v1metadata: name: nginx-secrets-store-inlinespec: containers:-image: nginx name: nginx volumeMounts:-name: secrets-store-inline mountPath: "/ mnt/secrets-store" readOnly: true volumes:-name: secrets-store-inline csi: driver: secrets-store.csi.k8s.com readOnly: true volumeAttributes: secretProviderClass: "vault-foo"

2) if the target cluster does not support the Inline Volume feature of CSI, we need to first create a pv using csi and the corresponding pvc instance. An example of a pv template is as follows:

ApiVersion: v1kind: PersistentVolumemetadata: name: pv-vaultspec: capacity: storage: 1Gi accessModes:-ReadOnlyMany persistentVolumeReclaimPolicy: Retain csi: driver: secrets-store.csi.k8s.com readOnly: true volumeHandle: kv volumeAttributes: providerName: "vault" roleName: "example-role" vaultAddress: http://172.21.12.21:8200 vaultSkipTLSVerify: "true" objects: | array:- | | objectPath: "/ foo" objectName: "bar" objectVersion: ""

You can get the vault in pod by referring to the specified pvc in the pod instance template. Here, we create a nginx application container instance in the ACK cluster using pv/pvc mode as an example, and mount the secretproviderclasses instance we created above:

Compared with secrets-manager and others using secret timing synchronization, although the implementation steps of using CSI to interface with specified Vault secret provider instances are complicated, and it is impossible to dynamically obtain the changes of Vault backend secret in the application, this scheme avoids the security risk of frequent transmission of secret on the synchronization link, and also serves the secret key disclosure that may be caused by describe po before, which is much higher in overall security. You can choose the way that suits you according to the actual application scenario.

The above is the content of this article on "what is the application scenario of Vault in Kubernetes". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

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.