No one wants to tell the truth about kubernetes secret

You really need Secret Objects? ？

Many people think that you should always use Kubernetes Secrets. When you start using Kubernetes when , I think that's right. Secret Objects The need is obvious .

But after a short time and many projects , I began to doubt its actual needs in deploying applications to production environments . Let's elaborate on .

What is? Secret

I hope we first clearly understand Kubernetes Upper Secret What is the object . I think the official document gives a clear definition .

Secret It contains a small amount of sensitive data （ For example, password 、 Token or key ） The object of . Such information may be placed in other ways Pod Spec Or container image . Use Secret This means that you don't need to include secret data in your application code .

Let's take a look at one Secret YAML Sample file ：

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
  namespace: default
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Kubernetes The mechanism ensures Secret Data security

Secret It has the following characteristics ：

• One pod Unable to access another pod Of Secret.
• If one is arranged on this node pod And need it , Then this node can use Secret.
• Secret The maximum allowed size of can only be 1 MB. This helps protect apiserver Memory resources and kubelet Free from abuse .
• default View Roles are not granted to Secrets Access rights of .

These are Kubernetes To provide Secret Some of the main security mechanisms implemented by the security baseline .

About production Secret It's the hard truth

Now let's look at it from the perspective of the attacker , How things are .

Let's start with Kubernetes The vulnerabilities mentioned in the document begin .

1. By default ,Kubernetes Secret Stored unencrypted in API The underlying data store of the server (etcd) in .

   actually , The secret data is base64 Coded . But you only need to apply the reverse base64 You can get pure data .

2. Any possession API Anyone with access can retrieve or modify Secret, Anyone who has access to etcd People can also .

3. Besides , Anyone who has permission to create in the namespace Pod Anyone can use this access right to read any in the namespace Secret; This includes indirect access , For example, create Deployment The ability of .

To solve these problems ,Kubernetes Some practices are recommended to ensure Secret Data security .

Kubernetes What suggestions does the document have ？

To avoid these pitfalls , The document provides some suggestions .

First , You should be Secrets Enable static encryption .

secondly , You should enable or configure restrict read and write Secret Of RBAC The rules .

Last , It should also be used RBAC And other mechanisms to limit which principals are allowed to create new Secret Or replace the existing Secret.

In production Secret problem

in other words , Some problems still exist , When we consider them in production , Things will surface . Let's see .

4. GitOps Has controlled the way we create and maintain infrastructure . therefore , If we need to create one Secret To store sensitive data , Do we want to add it to Ops Repository ？

If you don't do that , So users （ Developer 、 Administrator, etc ） Will have to deal with these secrets through imperative commands . If this is done , Then it opens the door for different types of attacks .

5. By the same pod In the container , You can visit pod Any secrets in .

The first 4 The problem is DevOps The biggest concern ： How we are in Kubernetes Available on the cluster Secret data , Follow at the same time GitOps Best practices .

Here are some alternatives I have found so far .

1. Hashicorp vault ：

HashiCorp Vault Is an identity based secret and encryption management system .Vault Provide encryption services controlled by authentication and authorization methods .

https://www.vaultproject.io/

Vault The beauty of is that it is an open source tool . You can set up your own instance and manage it yourself . You can also rely on their cloud platform .

2. Cloud provider Secret Managers

AWS、GCP and Azure Wait for cloud providers to provide Secret Manager, It can be used to protect the security of secret data and Kubernetes Use them on .

GCP Yes Google Secret Manager. This tutorial shows how to start in GKE（Kubernetes For Google） Upper use Google Secret Manager.

https://cloud.google.com/secret-manager

AWS Provide AWS Secret Manager, You can use it to manage your secret data .

https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html

Azure So it is with , It puts forward Key Vault, It can be done with Azure Kubernetes Service Integrate .

https://medium.com/swlh/integrate-azure-key-vault-with-azure-kubernetes-service-1a8740429bea

There are many other solutions that can provide the same services and better solve these problems .

Conclusion

We often say that none of them 100% Safe system , But as a DevOps And software engineers , Have the responsibility to find 、 Build and implement best practices , To improve infrastructure and provide customers with more secure systems .

Kubernetes Secret Still useful （ For example, when accessing private Docker When Repository ）, But we must combine them with more advanced tools and services to ensure system security .