第一天

部署模式

推荐体系结构的首选部署模式是执行HashiCorp Vault和Consul的不可变构建，并执行蓝/绿部署。因此，建议使用HashiCorp Packer等工具为不同平台构建不可变图像，HashiCorp提供了许多关于如何通过现有CI / CD编排构建这些元素的示例。

HashiCorp认识到有些组织没有采用这些模式，因此有许多配置管理模式可供安装，升级和配置Vault，可在不同的存储库中使用：

在Ansible Galaxy中，Brian Shumate的Vault角色
在Ansible Galaxy，Brian Shumate的领事角色
在Puppet Forge中，Vault模块
在Chef Supermarket，hashicorp-vault cookbook

建议您限制对Vault服务器的SSH访问，因为系统上的易失性存储器中存储了许多敏感项。

Vault发布周期

HashiCorp按季度发布Vault的主要版本，以及根据需要发布的次要版本，但至少每月发布一次，因此在组织中更新Vault的过程应该相当简化并且高度自动化。

监控

Vault会侦听单个端口（服务和管理）上的请求，如前所述，这是一个HTTP REST端点。默认情况下，这是TCP端口8200，并且有一个不受保护的状态端点，可用于监视群集的状态，如下所示：

curl -sS http://localhost:8200/v1/sys/health | jq
 {
  "initialized": true,
  "sealed": false,
  "standby": false,
  "performance_standby": false,
  "replication_performance_mode": "disabled",
  "replication_dr_mode": "disabled",
  "server_time_utc": 1545132958,
  "version": "1.0.0-beta1",
  "cluster_name": "vault-cluster-fc75786e",
  "cluster_id": "bb14f30a-6585-d225-ca12-0b2011de4b23"
}

还可以查询节点的单个密封状态，如下所示：

curl -sS http://localhost:8200/v1/sys/seal-status | jq
 {
  "type": "shamir",
  "initialized": true,
  "sealed": false,
  "t": 1,
  "n": 1,
  "progress": 0,
  "nonce": "",
  "version": "1.0.0-beta1",
  "migration": false,
  "cluster_name": "vault-cluster-fc75786e",
  "cluster_id": "bb14f30a-6585-d225-ca12-0b2011de4b23",
  "recovery_seal": false
}

在最佳实践设置中，HashiCorp Consul将监控Vault的状态，并可以通过DNS提供Service Discovery，或自动配置许多流行的开源负载均衡器，如官方参考体系结构指南中所述。 HashiCorp Learn Vault轨道中还提供了详细的分步指南。

遥测

在大规模运行Vault时，建议使用Vault的遥测输出结合遥测分析解决方案（如StatsD，Circonus或Datadog）来分析系统的性能。

审计

从Vault的角度来看，使用SIEM系统是跟踪访问代理的必要条件。 Vault通过Syslog，File或Unix套接字提供输出。大多数组织通过Splunk或使用ELK Stack中的工具来解析和评估此信息。审计输出是JSON数据，使组织能够轻松地解析和分析信息。

备份还原

解决方案的备份是通过Consul Snapshot Agent完成的，Consul Snapshot Agent可以将加密的备份自动上传到S3存储桶，也可以将备份保留在文件系统上，以便传统的企业备份解决方案将其运出。

失败场景

如果单个节点发生故障或最多两个节点发生故障，解决方案将继续运行而无需操作员干预。
如果Vault群集出现故障，则可以使用相同的Storage Backend配置重新设置它。
如果Consul集群失去法定人数，则可以选择重新获得服务可用性，尽管从RTO / RPO角度推荐的方法是故障转移到DR群集或提升性能副本。
如果要删除或不可用密封密钥，则唯一支持的方案是故障转移到DR群集或性能副本。

初始化仪式

虽然Vault中的每个操作都可以由API驱动，并且因此自动化，但初始化过程可确保Vault中的加密信任。持有Unseal Keys或最常见的恢复密钥的密钥持有者是Vault信托的监护人。对于任何Vault安装，此过程只会执行一次。

初始化过程完成后，Vault最容易受到攻击，因为存在根令牌。此根令牌会覆盖策略系统，并且仅在初始阶段用于配置生产身份验证方法和基本策略，或者在主身份验证方法不可用的情况下，在这种情况下需要重新生成根令牌。

建议在单个房间进行初始化仪式，在整个过程中将有操作员和保险柜密钥持有人在场，具体如下：

操作员启动Vault守护程序和初始化过程，如文档中所述，提供来自密钥持有者的公共GPG密钥，以及操作员拥有根令牌的公共GPG密钥。
Vault将返回GPG加密恢复密钥，这些密钥应在密钥持有者之间分配。
操作员使用根令牌加载初始策略并配置第一个身份验证后端，传统上是Active Directory或LDAP，以及审计后端。
操作员验证他们可以使用其目录帐户登录Vault，并可以添加更多策略。
运算符撤消根令牌。密钥持有人现在可以离开房间，保证没有人拥有对Vault的完全和未经审计的访问权限。

初始化

尽管应考虑以下参数，但脚注中引用的Vault文档中描述了完整的初始化选项集：

-root-token-pgp-key：将用于加密根令牌的Operator Public PGP密钥
-recovery-shares / threshold：要提供的密钥数量（基于密钥持有者的数量），以及执行恢复操作所需的密钥持有者的法定人数（通常是一半的密钥持有者加一个）
-recovery-pgp-keys：与上面的参数类似，来自密钥持有者的公共PGP密钥列表，以便提供密钥共享的加密输出

基本配置

为了在不需要使用根令牌的情况下继续进行进一步配置，必须配置备用身份验证方法。传统上，这是通过LDAP身份验证后端配置Active Directory / LDAP集成，或最近通过OIDC或Okta支持完成的。

组或声明定义为向Vault提供某些管理属性。

此外，策略定义为Vault中的管理操作（如添加挂载，策略，配置进一步的身份验证，审计等...），加密操作（如启动密钥轮换操作），以及最终消费模式，通常定义在以后根据要求。示例管理策略可以定义如下：

## Operations

# List audit backends
path "/sys/audit" {
  capabilities = ["read","list"]
}

# Create an audit backend. Operators are not allowed to remove them.
path "/sys/audit/*" {
  capabilities = ["create","read","list","sudo"]
}

# List Authentication Backends
path "/sys/auth" {
  capabilities = ["read","list"]
}

# CRUD operations on Authentication Backends
path "/sys/auth/*" {
  capabilities = ["read","list","update","sudo"]
}

# CORS configuration
path "/sys/config/cors" {
  capabilities = ["read", "list", "create", "update", "sudo"]
}

# Start root token generation
path "/sys/generate-root/attempt" {
  capabilities = ["read", "list", "create", "update", "delete"]
}
# Configure License
path "/sys/license" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

# Get Storage Key Status
path "/sys/key-status" {
  capabilities = ["read"]
}

# Initialize Vault
path "/sys/init" {
  capabilities = ["read", "update", "create"]
}

#Get Cluster Leader
path "/sys/leader" {
  capabilities = ["read"]
}

# Manage policies
path "/sys/policies*" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

# Manage Mounts
path "/sys/mounts*" {
  capabilities = ["read", "list", "create", "update", "delete"]
}

Auditor策略的示例可以定义如下：

## Audit
# Remove audit devices
path "/sys/audit/*" {
  capabilities = ["delete"]
}

# Hash values to compare with audit logs
path "/sys/audit-hash/*" {
  capabilities = ["create"]
}

# Read HMAC configuration for redacting headers
path "/sys/config/auditing/request-headers" {
  capabilities = ["read", "sudo"]
}

# Configure HMAC for redacting headers
path "/sys/config/auditing/request-headers/*" {
  capabilities = ["read", "list", "create", "update", "sudo"]
}

# Get Storage Key Status
path "/sys/key-status" {
  capabilities = ["read"]
}

An example Key Officer policy could be defined as follows:

## Key Officers
path "/sys/generate-root/update" {
  capabilities = ["create", "update"]
}

# Get Storage Key Status
path "/sys/key-status" {
  capabilities = ["read"]
}

# Submit Key for Re-keying purposes
path "/sys/rekey-recovery-key/update" {
  capabilities = ["create", "update"]
}

# Rotate Storage Key
path "/sys/rotate" {
  capabilities = ["update", "sudo"]
}

# Verify update
path "/sys/rekey-recovery-key/verify" {
  capabilities = ["create", "update"]
}

这些策略并非详尽无遗，虽然定义了三个配置文件，但在大多数组织中，角色隔离的运行范围更深。

值得注意的是，由于某些端点的敏感性，大多数组织选择使用控制组以便为某些配置更改要求批准工作流，例如，在添加或修改策略时，如下例所示：

# Create a Control Group for approvals for CRUD operations on policies
path "/sys/policies*" {
    capabilities = ["create", "update"]
    control_group = {
        ttl = "4h"
        factor "tech leads" {
            identity {
                group_names = ["managers", "leads"]
                approvals = 2
            }
        }
        factor "CISO" {
            identity {
                group_names = ["infosec"]
                approvals = 1
            }
        }
    }
}

通过这种方式，策略更改将需要来自“管理者”或“潜在客户”组的两个批准者，以及来自“信息安全”组的一个批准者。