Security/Icehouse/Heat

本页面记录了 OpenStack Icehouse 版本中 Heat 项目相关的安全细节。

ReST API 使用 keystone auth_token 中间件
ReST API 可以选择性地配置为允许用户/密码认证，当 Heat 在“独立”模式下使用时（使用本地 Heat 访问你无法控制的远程云）
与 CFN 兼容的 API 使用 heat 特定的 ec2token 中间件，该中间件依赖于 keystone ec2tokens 扩展进行签名验证

除了需要认证的 API 服务之外，还有一些独特的需要

当用户创建某些资源时，我们会执行延迟操作，例如在堆栈创建后对 AutoScaling 组进行调整的编排操作。我们需要代表用户执行这些操作的凭据，或者通过信任机制以显式的方式模拟用户。

一些资源会在堆栈的一部分中创建要部署在（隐式不可信）实例内的凭据。支持两种模式，一种是 Heat 在与堆栈所有者相同的项目（project）中创建用户，这需要堆栈所有者拥有足够的管理员角色来创建 keystone 用户（此模式在 Icehouse 中已被弃用，计划在 Juno 中删除）。另一种模式是代表堆栈所有者在 Heat 特定的域中创建用户，我们为每个堆栈创建一个项目，并创建与凭据（目前是 ec2 密钥对或随机生成的密码）关联的用户，这些凭据部署在实例内（例如，允许在软件配置完成后发出信号）

已实现的加密

无。

使用的加密

库

PyCrypto
Python hashlib
Requests (用于 heatclient HTTPS 使用 - 需要调查底层加密使用情况)

加密算法

算法	目的	可配置	实现	详情	源代码
AES	DB API 加密	否	PyCrypto	用于加密 Heat DB 中的敏感数据（例如凭据）	heat/common/crypt.py (使用 oslo crypto/utils.py)

哈希算法

算法	目的	可配置	实现	详情	源代码
sha1	模板资源签名	否	hashlib	哈希用于标识已定义资源的实现签名	engine/resources/template_resource.py
sha256	ec2token 中间件	否	hashlib	用于 ec2 签名请求的签名验证（通过 keystone ec2tokens 扩展）需要用于 AWS (CFN/CW API) 兼容性，因此无法配置。	heat/api/aws/ec2token.py

敏感数据

根据配置，Heat 会将几种类型的潜在敏感数据加密后存储在 DB 中

用户凭据

* 如果 Heat 配置了 deferred_auth_method = password，则 Heat 会加密并存储上下文中提供的密码，这是包含执行用户代表的延迟操作的资源的堆栈所必需的。此操作模式是 Icehouse 的默认设置，但 我们强烈建议部署者改用信任方法。

* 如果 Heat 配置了 deferred_auth_method = trusts，则 Heat 会在创建堆栈所有者与 Heat 服务用户之间的信任关系后加密信任 ID。这仅仅是一种预防措施，因为信任 ID 只能由 Heat 服务用户使用，因此此数据比指定密码方法时存储的用户凭据敏感性低得多。因此，推荐使用此方法（自 Havana 起作为选项可用，我们计划在 Juno 中将其设为默认值）

OS::Heat::RandomString 资源数据

RandomString 资源创建随机生成的字符串，这些字符串存储在 Heat DB 中。由于这些字符串的使用可能与凭据相关，因此我们将它们视为敏感数据并对其进行加密存储。

请参阅 engine/resources/random_string.py

AWS::IAM::AccessKey 资源数据

AccessKey 资源使用 keystone 创建 ec2 密钥对，并在 Heat DB 中缓存结果数据，包括密钥。由于此数据敏感，因此我们在存储时加密凭据 ID 和密钥对密钥。

请参阅 engine/resources/user.py

StackUser 子类

* OS::Nova::Server

Server 资源是 StackUser 子类，这是由于在通过 SoftwareDeployment 资源应用软件配置时，需要从实例内部发出信号的要求。这意味着当选择 POLL_SERVER_CFN 传输时，该资源会使用 keystone 创建 ec2 密钥对，并将结果加密后缓存到 Heat DB 中。

* SignalResponder 资源

AWS::CloudFormation::WaitConditionHandle

OS::Heat::HARestarter

AWS::AutoScaling::ScalingPolicy

OS::Heat::ScalingPolicy

这些资源都会创建一个用户和关联的 ec2 密钥对，以生成用于发出信号的预签名 URL，ec2 密钥对使用 keystone 创建，Heat 将结果加密后存储在 Heat DB 中。

密钥/证书

加密密钥 - 通过文件系统所有权/权限保护，在 /etc/heat/heat.conf auth_encryption_key 中指定)

密码

必须在 Heat 中启用 SSL/TLS，以防止客户端通过网络以明文形式发送密码、令牌和其他敏感数据。

潜在改进

将信任设为默认值，我们应该避免存储用户凭据并存储信任 ID。
所有部署都应使用堆栈域用户，以避免在创建某些资源时需要管理员角色，并提供对部署在不可信实例中的凭据的更好隔离。
摆脱对 ec2 签名 URL 的依赖，使其成为可选的，转而支持原生认证（例如来自 ceilometer 的基于信任的警报通知）。对于 SoftwareDeployments，已经可以选择指定原生或基于 ec2tokens 的传输，但我们仍有一些工作要做，才能在 keystone 中没有可用的 ec2tokens 扩展的情况下访问所有功能（特别是上述警报通知，我们计划在 Juno 中修复）
研究替代方案，以避免为实例的遥测部署随机密码和 ec2 密钥对，例如 OAuth 和 X509 已讨论过
理想情况下，我们不希望在我们的树中拥有 ec2tokens 中间件，最好将其放在 keystoneclient 树中，例如，可以使用通用实现，供提供 AWS 兼容 API 的各种项目使用（例如 nova ec2 API）