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

How to choose the Secrets manager in Kubernetes, I believe many inexperienced people do not know what to do about it. Therefore, this article summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Secrets is an object type in Kubernetes, which is used to store sensitive information such as passwords, private keys, passwords, etc. So in Kubernetes, how to manage Secrets effectively to ensure the security of these confidential data?

Secrets management built into Kubernetes

Kubernetes provides a built-in mechanism for storing configuration values that users want to keep secret. They have access control over specific namespaces, and their contents are not displayed in kubectl get or describe output by default. They are base64-encoded, so even if the content is extracted directly from the kubectl, the content is not immediately apparent.

These secrets are stored as plaintext on the cluster's etcd servers, and these secrets are visible online when the etcd cluster is synchronized unless etcd is configured to use TLS to encrypt communications. In addition, anyone who has or can gain root access to any node in the cluster can read all confidential data by impersonating kubelet.

Therefore, unless your security requirements are very low, it is recommended that you use a third-party solution to protect confidential data.

Secrets Manager from a third party

There are three basic categories of Secrets management solutions in Kubernetes that you should consider if your requirements exceed the very low conditions set by the built-in Secrets functionality:

Secrets management solutions from cloud providers

Run your own open source solutions, whether in the cluster or around

Proprietary solutions from a variety of suppliers.

1. Secrets store of cloud management platform

If you are running in one of the major public clouds and have purchased its Secrets management services, or if you just want to create it quickly without considering potential vendor locking, then a cloud-hosted solution, such as AWS Secrets Manager, is a good choice.

2. Open source Secrets manager

If you use bare metal, you may need to choose a software solution if you want to avoid cloud vendor locking, worry about the security of the cloud provider solution, or need to integrate with existing enterprise standards.

1) Vault

By far, the most widely used, popular, and feature-rich Secrets manager in Kubernetes is Vault. Vault is more feature-rich and consistent than cloud-managed solutions and works perfectly with EKS,GKE, local clusters, and any location that may be running Kubernetes. There is also controversy over Vault-based cloud-managed storage, mainly because it is difficult to set up and configure high-performance HA Vault clusters, but can be mitigated through built-in automation and support.

It also provides several unique features:

The completely private Cubbyholes,Token token is the only person who can access the data.

Dynamic secrets. Vault can automatically create accounts and credentials in the database and cloud IAM.

The PKI certificate and SSH certificate generation engine, which allows certificates to be generated and stored using a single API call.

Cross-region, cross-cloud, cross-data center replication, and support filters to limit data that should not be transferred across clusters.

Supports a variety of authentication methods and supports MFA when needed.

2) Sealed Secrets

One benefit of Kubernetes styling is that the configuration is based on a set of declarative json or yaml files that can be easily stored in version control and can automate operational changes into a single fact based on Git. This means that each change in the load configuration can go through the same pull request and peer review process as the application code.

However, traditional Secrets management methods such as Vault, and all of the above cloud storage, introduce a second real source for Secrets data managed outside the Git-another potential change / failure source that is tracked completely independently in the cluster. This can complicate troubleshooting and also complicate audit logging of all cluster configuration changes.

Sealed Secrets is designed to solve this problem. It works by running a controller with secret data and a public key in a Kubernetes cluster and providing an encrypted string that can be used in a standard configuration file and can only be decrypted by the controller that contains the private key.

That is, you can store your security credentials directly in the configuration file in Git and share the Git repository with all who need to access it, but none of these users can access those credentials. This can be used to create GitOps-based secure workflows.

After reading the above, have you mastered how to select the Secrets manager in Kubernetes? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.