每个人都有秘密。软件开发人员有很多。通常需要这些机密API令牌、TLS私钥、数据库密码、SSH密钥和其他敏感数据，才能使服务正常运行并与其他服务安全地交互。今天，我们将分享我们在Cloudflare构建的一个工具，用于将机密安全地分发到我们的对接生产应用程序：PAL。在Github上提供PAL：github.com/cloudflare/pal虽然PAL目前还没有被积极开发，但我们发现它是一个有用的工具，我们认为社区将从它的源代码中获益。我们认为，最好是将这个工具开源并允许其他人使用代码，而不是让它隐藏起来不被维护。生产中的秘密个人创作的CC BY 2.0图像你是怎么得到这些秘密的？如果您是项目中唯一的开发人员，或者是少数几个开发人员之一，那么您可能会将源代码中的秘密放在版本控制系统中。但是，如果您只是将机密以明文形式存储在代码中，那么每个有权访问源存储库的人都可以读取这些机密并将其用于邪恶的目的（例如，窃取API令牌并假装是授权客户机）。此外，像Git这样的分布式版本控制系统将在任何克隆存储库的位置下载机密的副本，而不管是否需要，并将该副本永久保存在提交历史中。对于一个很多人（包括在无关系统上工作的人）都可以访问源代码管理的公司来说，这不是一个选择。另一个想法是将机密保存在一个安全的地方，然后在构建时将它们嵌入到应用程序构件（二进制文件、容器、包等）中。这对于现代的CI/CD工作流来说可能会很尴尬，因为它会为不同的环境（例如生产、登台、开发）产生多个并行的工件集。一旦你拥有了带有秘密的工件，它们本身就变成了秘密，你必须限制对包含秘密的"武装"包的访问。考虑一下去年的发现，Twitter的Vine服务的源代码可以在公共Docker存储库中找到。不仅服务的源代码泄露了，而且允许Vine与其他服务交互的API密钥也可用。接到通知后，Vine支付了1万美元。管理和部署机密的一种更先进的技术是使用秘密管理服务。秘密管理服务可以用来创建、存储和轮换机密，也可以将它们分发给应用程序。秘密管理服务充当网关守卫，允许访问访问控制策略规定的某些应用程序的某些机密。如果应用程序希望获得对机密的访问权，则向机密管理器验证自己的身份，机密管理器检查权限以查看应用程序是否已授权，如果已授权，则发送机密。有许多选项可供选择，包括保险库、Keywhiz、Knox、秘书、dsss甚至Docker自己的秘密管理服务。只要身份/授权系统已经到位，秘密管理器就是一个很好的解决方案。然而，由于大多数身份验证系统都涉及到客户已经掌握了一个秘密，这就出现了鸡和蛋的问题。身份引导一旦我们验证了服务的身份，我们就可以对该服务可以访问的内容做出访问控制决策。因此，我们必须解决的真正问题是服务标识的引导问题。当服务与单独的机器紧密绑定时，这个问题有很多解决方案（例如，我们可以简单地在每台机器上安装主机级凭据，甚至可以使用机器的硬件来识别它）。像amazonaws这样的虚拟机平台有基于机器的api，用于主机级身份识别，比如IAM和KMS）。集装箱化服务的生命周期要灵活得多—实例可能出现在许多机器上，并且可能会随着时间的推移而变化。此外，任意数量的受信任和不受信任的容器可能同时在同一主机上运行。因此，我们需要的是一个属于服务的标识，而不是属于机器的标识。每一个申请都需要一个身份证来向保镖证明他们在俱乐部秘密的客人名单上。引导位于容器中的服务的标识并不是一个解决的问题，而且大多数现有的服务都深度集成到容器编排中（Kubernetes、Docker Swarm、Mesos等）。我们遇到了容器标识引导的问题，我们需要一些与或当前应用程序部署堆栈（Docker/Mesos/Marathon）一起工作，但不局限于给定的编排平台。输入PAL我们使用Docker容器在一个共享的、通用的Mesos集群上部署许多服务。为了解决Docker环境中的服务身份引导问题，我们开发了PAL，它代表核武器安全设备Permissive Action Link。PAL确保机密只在生产中可用，并且只有在作业被授权运行时才可用。PAL使得在服务的配置中只保留加密的机密成为可能，同时确保这些机密只能由批准的环境（例如，生产或登台环境）中的授权服务实例解密。如果这些凭据用于标识请求访问机密的服务，那么PAL将成为容器标识引导解决方案，您可以轻松地在其上部署secret manager。工作原理PAL的模式是秘密以加密的形式提供，或者嵌入容器中，或者作为运行在编排框架（如apachemesos）中的作业的运行时配置。PAL允许在建立服务身份后在运行时解密机密。这些凭证可以允许经过身份验证的服务间通信，这将允许您将服务机密保存在中心存储库（如Hashicorp的Vault、KeyWhiz或其他存储库）中。这些凭证还可以用于颁发服务级别凭据（例如内部PKI的证书）。如果没有PAL，您必须在您的基础结构中分发这些工具本身所需的身份凭证。PAL由两个组件组成：一个小型的容器内初始化工具PAL，它请求机密解密并安装解密的secret，另一个名为pald的守护进程在集群中的每个节点上运行。pal和pald通过Unix套接字相互通信。pal工具被设置为每个作业的入口点，它向pald发送加密的秘密。然后，pald会识别制作作业的进程，并确定是否允许它访问请求的机密。如果是这样，它代表作业解密机密并将明文返回给pal，pal将明文作为环境变量或文件安装在调用作业的容器中。PAL目前支持两种加密方法PGP和Red十月，但它可以扩展到支持更多。PAL-PGP公司PGP是一种流行的加密形式，从90年代初就开始使用了。PAL允许您使用主机上安装的PGP密钥加密的机密。当前版本的PAL没有在每个密钥级别应用策略（例如，只有带有Docker标签a的容器才能使用key 1），但是它可以很容易地扩展到这样做。朋友红十月红色十月模式用于非常高价值的机密，需要手动管理或多人控制。我们早在2013年10月就公开了Red的来源。它有一个很好的特性，能够加密一个秘密，这样就需要多个人来授权解密。在PAL-RO典型设置中，集群中的每台机器都将被配置一个红色的十月帐户。在计划运行容器之前，机密所有者将解密机密的能力委派给要运行容器的主机。当容器启动时，pal调用pald，pald使用机器的Red十月凭证通过调用Red十月服务器来解密秘密。授权可以是有限的时间，也可以是多次解密。一旦代表团用完了，红色十月就没有办法解密秘密了。这两种模式对于保护高价值的机密是非常宝贵的，因为红色十月提供了额外的监督和控制。对于价值较低的秘密，PGP提供了一种非交互式的体验，可以很好地与临时容器配合使用。授权详细信息秘密管理工具的一个重要部分是确保只有经过授权的实体才能解密机密。PAL使您能够通过利用现有的代码签名基础设施来控制哪些容器可以解密秘密。机密和容器都可以被赋予PAL将尊重的可选标签。标签定义了哪些容器可以访问哪些机密—容器必须具有它访问的任何机密的标签。标签是对安全策略的命名引用。一个示例标签可以是"productionteamsecret"，它表示一个秘密应该符合生产团队的秘密策略。要绑定密码标签的授权文本。这些授权允许您使用PAL来控制何时以及在什么环境下可以解密机密。通过打开带有soupasscred选项的Unix套接字，我们使pald能够为每个请求获取调用者的进程级凭证（uid、pid和gid）。然后可以使用这些凭证来标识容器并为其分配标签。标签允许PAL参考预定义的策略并授权容器接收机密。为了获得容器上的标签列表，pald使用调用进程的进程id（pid）从Linux获取其cgroups（通过读取和解析/proc//cgroups）。cgroups的名称包含Docker容器id，我们可以使用它通过Docker的inspect调用获取容器元数据。这个容器元数据携带Docker LABEL指令在构建时分配的标签列表。容器及其标签必须使用代码完整性工具绑定在一起。朋友支持