数据加密可以确保敏感数据在存储、传输和处理过程中得到有效的保护，降低数据泄露的风险。
Kubernetes中的敏感数据
Kubernetes为应用开发者提供了Secrets和ConfigMaps模型，用于保存应用Pod在运行时需要加载、使用的数据。在设计上，Secrets用于保存敏感信息，例如数据库密码、应用证书、认证Token等；ConfigMaps主要用于保存应用所依赖的配置信息，例如应用的启动配置项等。对于K8s集群中的敏感数据，建议您遵循K8s的最佳实践，通过Secrets（而非ConfigMaps）进行存储。
K8s Secrets的相关技术概念如下：
用户访问APIServer创建Secrets时，Secrets会以Base64明文编码的形式存储到集群etcd中。
拥有RBAC权限的用户，可以访问APIServer并获取Secrets的明文数据。
应用Pod可以挂载Secrets，将它作为文件或环境变量使用。
应用Pod使用Secrets时，Secrets中的敏感数据会以tmpfs格式存储在节点文件系统中。
K8s Secrets作为K8s应用承载敏感数据的载体，本身并不具备敏感信息的保护能力。在使用过程中，可能会遇到如下问题：
一些关键的敏感数据，需要开发者和安全管理人员在应用系统实施前确定敏感数据管理方案，明确如何存储敏感数据。
如何在不影响敏感数据加载和使用的前提下，保护其在读写和传输阶段的安全性？
云服务厂商有哪些安全方案可以帮助保护敏感数据？
下文从云服务商提供的敏感数据管理安全方案和面向应用开发者的敏感数据管理最佳安全实践两个维度帮您解决以上问题。
安全方案
基于云上安全责任共担模型，云服务商有责任保护管控侧配置和敏感信息的安全性，同时提供敏感数据管理的安全方案，帮助您提升应用的安全水位。推荐使用云上密钥管理服务保护您的敏感数据。
云服务商都会提供密钥管理服务。例如，阿里云KMS密钥管理服务提供专业的密钥生命周期管理和数据加解密，可以帮助您简化应用系统接入流程。关于阿里云KMS密钥管理服务的更多信息，请参见什么是密钥管理服务。
在应用系统开发部署的供应链流程中，任何一个环节对敏感数据的硬编码都有可能导致泄露风险。通过使用云上密钥管理服务，您可以在应用开发、测试、构建等生命周期流程中使用统一方式进行敏感数据的读写，避免硬编码出现。同时，云上的密钥管理服务支持自动化的密钥轮转能力，进一步降低了敏感数据泄露传播的安全风险，同时也可帮助企业应用满足合规需求。
最佳安全实践
基于云服务商提供的敏感数据管理安全方案，应用开发运维人员需要负责自身业务敏感数据的安全性。以下为业务侧推荐实施的敏感数据管理最佳安全实践。
RBAC访问控制
Secrets作为K8s系统中的基础模型，通过RBAC实现对Secret实例的访问权限控制是基本且必要的安全要求，在集群的日常运维开发中应该遵循权限最小化原则进行授权，避免在下发凭证中绑定全局Secret读写权限，并及时吊销可能泄露的集群访问凭证。
供应链安全加固
关于敏感数据的读取使用会贯穿应用制品生命周期的各阶段，需要在组织流程上加强对敏感数据安全的风险意识，规范敏感数据使用，严禁在应用模板、代码仓库、配置文件中硬编码敏感信息。在制品供应链生命周期中统一使用密钥管理服务进行管理，同时，企业内部安全管理运维团队可针对供应链各环节增加自动化安全扫描卡点，从源头上防止敏感信息的传播和泄露。
审计和监控
在企业应用系统中，涉及敏感数据生命周期管理和读写使用的所有操作均应接入审计日志，保证针对敏感信息的操作可溯源，同时接入运行时刻监控机制，例如，针对应用中存储敏感信息的路径设置可疑读写监控告警，对云账号AK设置泄露告警等安全设置。当发生敏感数据泄露时，日志和告警可以帮助企业运维快速定位问题，判断影响面，同时及时进行相关止血措施。
使用临时凭证，定期或自动轮转密钥
请勿在应用系统中使用例如账号AK的固定密钥，推荐使用临时凭据。当密钥发生泄露时，获得临时凭据的攻击者只有一个短暂的窗口期进行下一步的探查和攻击，这无疑增加了攻击难度，也给系统运维人员提供了封堵和修复系统漏洞的机会，试想如果凭据是永久的，可能应用系统的彻底修复需要成倍的难度。同样的道理，当您使用云上KMS密钥管理服务中的密钥时，推荐定期轮转或开启密钥自动轮转特性，提升应用安全防御能力。
通过加密保护K8s集群中的敏感数据
当需要在K8s Secrets和ConfigMaps存储敏感数据时，建议基于云上KMS密钥管理服务，对Secrets和ConfigMaps中的敏感数据进行加密。在应用系统挂载使用Secrets和ConfigMaps时，可按需对加密后的数据进行解密，从而避免将明文数据储存在Secrets和ConfigMaps中。
使用信封加密并保护好最后一把密钥
信封加密和直接使用云上管理服务提供的密钥进行直接加解密明文数据的方式不同，信封加密使用一个独立的数据加密密钥，并将其加密后封入信封中传递使用，业务侧的敏感信息可以在本地实现离线的加解密，避免上传云端传输过程中的泄露，同时解决了云服务商不信任问题。同时，对于数据量较大的加解密场景，离线的计算过程也避免了云上传输和计算的开销，有效提升计算性能并降低成本。关于信封加密的更多信息，请参见使用KMS信封加密在本地加密和解密数据。
最后一把密钥的安全问题是KMS加解密场景中的普遍问题，在信封加密过程中，同样需要在云上放置一把KEK密钥用于加解密数据密钥，此时通用的方案是使用类似RAM的访问控制服务，在最小化授权的前提下保证密钥安全性。在应用侧，需要限制读取云上密钥的RAM凭证的可见范围，同时使用可自动轮转的临时凭证，推荐在容器应用中使用类似RRSA应用维度的隔离机制保护RAM凭证的安全性。