为Kubernetes应用程序提供数据库凭据一直是操作上的挑战。为了获得最佳的安全性，我们理想情况下需要对数据库凭据实现以下要求：每个Kubernetes吊舱都应该有一套唯一的凭证当pod终止时，应禁用或删除凭据凭据应该是短期的，并经常轮换访问应该受到应用程序功能的限制，一个只需要读取一个特定表的系统，应该具有授予这个特定目的的数据库访问权限虽然这些要求对于在发生攻击时减小爆炸半径至关重要，但在操作上具有挑战性。现实是，没有自动化，就不可能满足他们。HashiCorp Vault通过允许操作员为应用程序提供动态生成的凭据来解决此问题。Vault管理凭据的生命周期，根据需要进行轮换和吊销。在这篇博文中，我们将了解Kubernetes的Vault集成如何允许操作员或开发人员使用元数据注释将动态生成的数据库机密注入Kubernetes pod。集成自动处理与保险库的所有身份验证和机密管理，应用程序只需从文件系统读取机密。»目录集成工作流摘要先决条件金库概论为PostgreSQL配置动态机密在Vault中配置Kubernetes身份验证创建允许访问的机密向库伯内特斯部署注入秘密摘要»集成工作流摘要当一个新的部署提交给Kubernetes时，一个不断变化的webhook修改了部署，注入了一个保险库侧车。这个侧车管理对保险库的认证和机密的检索。检索到的机密将写入应用程序可以读取的pod卷装入。例如，我们可以使用Vault为PostgreSQL数据库动态生成数据库凭据。添加下面示例中显示的注释会自动将由db creds角色控制的机密注入pod。API版本：应用程序/v1种类：部署元数据：名称：web部署标签：应用程序：web规格：副本：1选择器：匹配标签：web应用程序模板：元数据：标签：应用程序：web注释：vault.hashicorp.com/agent-注入："真"vault.hashicorp.com/agent-注入机密数据库creds："database/creds/db app"https://www.vaultproject.io/docs/platform/k8s/injector/index.html按照惯例，Vault将在路径/Vault/secrets/插入这些文件，下面的代码片段显示了此文件的示例。用户名：v-kubernet-db-app-QDTv8wn6oGze6aGxuYbQ-1576778182密码：A1a-7kHXqX0jdh8ys74H在此之前，我们将介绍在Kubernetes集群中部署和配置Vault的过程，并学习如何将PostgreSQL凭据注入Kubernetes部署中。让我们介绍一些HashiCorp Vault的核心概念。»先决条件要尝试本博客中列出的功能，您需要一个带有Vault的Kubernetes环境。保险库可以使用最新版本的头盔图表安装在Kubernetes上：https://www.vaultproject.io/docs/platform/k8s/helm/index.html。如果您无法访问带有Vault的Kubernetes群集，并希望尝试此博客中的功能，则可以使用安装了Kubernetes和Vault的联机Instruqt环境：https://instruqt.com/hashicorp/tracks/kubernetes-secrets-with-vault/或者，您可以使用Shipyard创建一个基于本地Docker的Kubernetes集群，并预装了Vault：https://shipyard.demo.gs快速安装：卷曲https://shipyard.demo.gs/vault|巴什本文中提到的所有示例配置都可以从GitHub克隆：https://github.com/nicholasjackson/demo-vault/tree/master/dynamic-secrets-k8。»金库概论Vault围绕三个主要概念构建：秘密身份验证政策在本节中，我们将回顾这些概念在Vault中的工作原理。»秘密您可以拥有静态机密，如API密钥或信用卡号，也可以具有动态机密，如自动生成的云或数据库凭据。Vault按需生成动态机密，而您将接收已预定义的静态机密。对于静态机密，必须创建和管理机密的生命周期。例如，您可以将电子邮件帐户密码存储在保险库中，但需要确保它定期更改。使用动态机密，可以将创建和管理机密生命周期的责任委派给Vault。例如，您将PostgreSQL数据库的根凭据授予Vault，并授予它代表您创建凭据的访问权限。当您要登录到数据库时，您需要Vault提供凭据。Vault连接到数据库并生成一组受限访问凭据。这些不是永久性的，而是租赁的。Vault管理生命周期，自动旋转密码并在不再需要密码时取消访问。纵深防御的一个关键特性是轮流认证。一旦出现漏洞，具有严格生存时间（TTL）的证书可以显著减小爆炸半径。»身份验证要访问保险库中的机密，您需要经过身份验证；身份验证采用可插拔后端的形式。例如，您可以使用Kubernetes服务帐户令牌对Vault进行身份验证。对于人工访问，您可以使用类似GitHub令牌的东西。在这两种情况下，Vault不直接存储凭据；而是使用受信任的第三方来验证凭据。使用Kubernetes服务帐户令牌，当应用程序尝试使用Vault进行身份验证时，Vault会调用Kubernetes API以确保令牌的有效性。如果令牌有效，它将返回一个内部托管的保险存储令牌，供应用程序用于将来的请求。»政策策略通过定义经过身份验证的用户可以执行哪些机密和哪些管理操作，从而将机密和身份验证联系在一起。例如，操作员可能有一个策略，允许他们为PostgreSQL数据库配置机密，但不生成凭据。应用程序可能具有创建凭据的权限，但不能配置后端。Vault策略允许您根据角色正确地划分责任。#允许创建和配置数据库和角色的策略路径"数据库/角色/*"{能力=["创建"，"读取"，"更新"，"删除"，"列表"]}路径"database/config/*"{能力=["创建"，"读取"，"更新"，"删除"，"列表"]}#允许为向导数据库创建凭据的策略路径"数据库/creds/wizard"{能力=["读取"]}»机密-为PostgreSQL配置动态机密在配置Vault之前，您需要一个数据库。在本例中，为了方便起见，您将把数据库部署到Kubernetes。您还可以使用托管云产品或运行在虚拟机或物理硬件上的数据库。让我们使用示例repo中的示例部署数据库，并在Kubernetes集群中创建一个部署。示例文件还创建了一个名为postgres的服务，该服务指向由部署创建的pod。kubectl apply-f配置/邮政信箱.yml虽然本例侧重于PostgreSQL的配置，但是配置、创建角色和生成凭据的工作流适用于任何数据库。»启用PostgreSQL机密后端在配置连接和角色之前，首先需要启用数据库后端。vault机密启用数据库一旦秘密引擎被启用，你就可以开始创建角色了。»创建数据库角色角色配置控制用户有权访问的表和凭据的生命周期。通常为每个连接创建多个角色。例如，用户可能需要对表进行读操作，但用户可能需要对表进行读操作。您可以通过将配置写入路径database/roles/来创建角色。让我们更深入地了解一下这些参数。db_name参数引用数据库连接的名称；我们将在下一步中为数据库配置连接。现在，您可以设置值向导，因为这将是创建连接时的名称。当用户或应用程序请求凭据时，Vault将执行creating_statements参数中定义的SQL语句。本例在数据库向导中创建一个角色，该角色允许对所有表进行select访问。creation_语句是PostgreSQL标准SQL语句。SQL语句可以包含在运行时动态替换的模板变量。如果查看下面的create SQL语句，将看到三个模板变量{{name}}、{password}}}和{expiration}}：{{name}}是Vault将生成的随机生成的用户名{{password}}是随机生成的密码{{expiration}}是在该数据之后凭据不再有效创建角色{name}}，登录密码为{PASSWORD}}，有效期至{{expiration}}}；将SCHEMA public中所有表的SELECT授予"{{name}}"；当Vault运行此语句时，它将用唯一生成的值替换模板变量。例如，前面的语句将变成：创建角色"abc3412vsdfsfd"，登录密码为"sfklasdfj234234fdsfdsd"，有效期至"2019-12-31 23:59:59"；将SCHEMA public中所有表的SELECT授予"'abc3412vsdfsfd'"；当机密过期的TTL时，Vault将运行revocation_statements参数中定义的SQL语句。下面的语句将禁用由模板变量{{name}}定义的PostgreSQL用户。改变角色{name}}NOLOGIN；最后两个参数是default_ttl和max_ttl。default_ttl定义机密的租约长度；此值设置为1h；这意味着您需要每小时更新一次机密租约。租约告诉保险库你