开源KMS之vault part7

原创

保持热爱奔赴山海

发布于 2024-06-03 10:20:09

670

发布于 2024-06-03 10:20:09

配置相关策略

创建策略文件

vim secret2_read_policy.hcl 内容如下

path "secret2/data/creds" {
 capabilities = ["read"]
}
path "secret2/data/creds2" {
 capabilities = ["read","update"]
}

如果对于v1版本的kv secret引擎，则不需要data路径，类似如下：

path "secret2/creds" {
 capabilities = ["read"]
}
path "secret2/creds2" {
 capabilities = ["read","update"]
}

基于文件创建policy策略

$ vault policy write secret2-readonly ./secret2_read_policy.hcl
Success! Uploaded policy: secret2-readonly

说明： "secert2-readonly" 是策略的名称，这个可以自定义。

tips: policy的命令行删除方法： vault policy delete my-policy

生成 Token 并指定策略

生成对"kv/secret2"具有只读权限的 Token, 执行：

$ vault token create -policy="secert2-readonly"
WARNING! The following warnings were returned from Vault:
 * Policy "secert2-readonly" does not exist
Key Value
--- -----
token hvs.CAESIOZOh2uZDQaVdtwRZDQv02zK9w6rsbt2TKnSomBh6lQyGh4KHGh2cy5TNlBYRVR5TlZkTEFxZmlCYWxmaVNVNks
token_accessor 90ADAEVk0JnjhYL5rSn49V49
token_duration 768h
token_renewable true
token_policies ["default" "secert2-readonly"]
identity_policies []
policies ["default" "secert2-readonly"]

此处生成了新的 Token:

hvs.CAESIOZOh2uZDQaVdtwRZDQv02zK9w6rsbt2TKnSomBh6lQyGh4KHGh2cy5TNlBYRVR5TlZkTEFxZmlCYWxmaVNVNks

有效期 768 小时，也就是32天。

列出上面这个token的明细情况

$ vault token lookup hvs.CAESIOZOh2uZDQaVdtwRZDQv02zK9w6rsbt2TKnSomBh6lQyGh4KHGh2cy5TNlBYRVR5TlZkTEFxZmlCYWxmaVNVNks
Key Value
--- -----
accessor 90ADAEVk0JnjhYL5rSn49V49
creation_time 1717211033
creation_ttl 768h
display_name token
entity_id n/a
expire_time 2024-07-03T11:03:53.450498193+08:00
explicit_max_ttl 0s
id hvs.CAESIOZOh2uZDQaVdtwRZDQv02zK9w6rsbt2TKnSomBh6lQyGh4KHGh2cy5TNlBYRVR5TlZkTEFxZmlCYWxmaVNVNks
issue_time 2024-06-01T11:03:53.450515803+08:00
meta <nil>
num_uses 0
orphan false
path auth/token/create
policies [default secert2-readonly]
renewable true
ttl 761h36m12s （需要在到期前renew否则会失效）
type service

TIPS：

vault token lookup 除了可以基于token查询，还可以基于-accessor 查询，

例如：vault token lookup -accessor 90ADAEVk0JnjhYL5rSn49V49

列出当前存在的policy：

$ vault policy list
default
secret2-readonly
root

查看新创建的policy的内容：

$ vault policy read secret2-readonly

注意：我们上面启用的v2版本的kv secret引擎，因此policy里面的path路径必须使用类似 path_name/data/keyname这种写法，如果是v1的kv secret引擎，可参考https://zhuanlan.zhihu.com/p/651849007这篇来实践。

使用上面生成的token登录

$ export VAULT_ADDR='http://192.168.31.181:8200'

$ vault login hvs.CAESIOZOh2uZDQaVdtwRZDQv02zK9w6rsbt2TKnSomBh6lQyGh4KHGh2cy5TNlBYRVR5TlZkTEFxZmlCYWxmaVNVNks
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
Key Value
--- -----
token hvs.CAESIOZOh2uZDQaVdtwRZDQv02zK9w6rsbt2TKnSomBh6lQyGh4KHGh2cy5TNlBYRVR5TlZkTEFxZmlCYWxmaVNVNks
token_accessor 90ADAEVk0JnjhYL5rSn49V49
token_duration 767h56m46s
token_renewable true
token_policies ["default" "secert2-readonly"]
identity_policies []
policies ["default" "secert2-readonly"]

查看kv内容

$ vault kv get secret2/creds
=== Secret Path ===
secret2/data/creds
======= Metadata =======
Key Value
--- -----
created_time 2024-06-01T01:11:59.425429041Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 5
======= Data =======
Key Value
--- -----
aliyun_oss [ak-22222,secret-11111]
huawei_oss [ak-333,secret-444]
tencent_oss [ak-22222,secret-11111]

如果查询一个不在policy里面的路径，则会报403提示无权限

$ vault kv get secret2/creds2
Error reading secret2/data/creds2: Error making API request.
URL: GET http://192.168.31.181:8200/v1/secret2/data/creds2
Code: 403. Errors:
* 1 error occurred:
 * permission denied

再测试下更新数据

例子1
$ vault kv put secret2/creds2 dba_userpass='aaaa' 
=== Secret Path ===
secret2/data/creds2
======= Metadata =======
Key Value
--- -----
created_time 2024-06-01T06:29:42.182167663Z
custom_metadata <nil>
deletion_time n/a
destroyed false
version 3
# 可以看到尝试更新成功，因为之前的策略设置的是对creds2的read、update


例子2
$ vault kv put secret2/creds dba_userpass='aaaa'   
Error writing data to secret2/data/creds: Error making API request.
URL: PUT http://192.168.31.181:8200/v1/secret2/data/creds
Code: 403. Errors:
* 1 error occurred:
 * permission denied
# 可以看到尝试更新失败，因为之前的策略设置的是对creds的read

策略中的Capabilites说明

下面只列出常用的几个：

create(POST/PUT) 允许在指定路径创建数据。只有很少的Vault部件会区分 create 和 update，所以大多数操作同时需要 create 以及 update 能力。需要区分二者的部分会在相关文档中说明。
read(GET) 允许读取指定路径的数据
update(POST/PUT) 允许修改指定路径的数据。对多数Vault部件来说，这隐含了在指定位置创建初始值的能力
delete(DELETE) 允许删除指定路径的数据
list(LIST) 允许罗列指定路径的所有值。要注意的是，经由 list 操作返回的键是未经策略过滤的。请勿在键名中编码敏感信息。不是所有后端都支持 list 操作

内置策略

$ vault read sys/policy/default

策略示例

注意：

v1 和 v2 版本的kv secret引擎，写的策略规则还是有点区别的。

v2的路径里面需要加/data/ ，v1 则不需要。

下面的这几个来自官方文档上的例子，都是适配kv secret v1版本的。

tips: 下面是一个更复杂的策略

# This section grants all access on "secret/*". Further restrictions can be
# applied to this broad policy, as shown below.
path "secret/*" {
 capabilities = ["create", "read", "update", "delete", "list"]
}
# Even though we allowed secret/*, this line explicitly denies
# secret/super-secret. This takes precedence.
path "secret/super-secret" {
 capabilities = ["deny"]
}
# Policies can also specify allowed, disallowed, and required parameters. Here
# the key "secret/restricted" can only contain "foo" (any value) and "bar" (one
# of "zip" or "zap").
path "secret/restricted" {
 capabilities = ["create"]
 allowed_parameters = {
 "foo" = []
 "bar" = ["zip", "zap"]
 }
}

策略基于路径匹配来验证一个请求所需要的能力。一个策略路径可以精准匹配一个确切的路径，或者可以使用 * 模式指定前缀匹配：

# Permit reading only "secret/foo". An attached token cannot read "secret/food"
# or "secret/foo/bar".
path "secret/foo" {
 capabilities = ["read"]
}
# Permit reading everything under "secret/bar". An attached token could read
# "secret/bar/zip", "secret/bar/zip/zap", but not "secret/bars/zip".
path "secret/bar/*" {
 capabilities = ["read"]
}
# Permit reading everything prefixed with "zip-". An attached token could read
# "secret/zip-zap" or "secret/zip-zap/zong", but not "secret/zip/zap
path "secret/zip-*" {
 capabilities = ["read"]
}
另外，路径当中可以使用 + 代表路径中一个段内任意长度的字符（从 Vault 1.1 开始支持）：
# Permit reading the "teamb" path under any top-level path under secret/
path "secret/+/teamb" {
 capabilities = ["read"]
}
# Permit reading secret/foo/bar/teamb, secret/bar/foo/teamb, etc.
path "secret/+/+/teamb" {
 capabilities = ["read"]
}

我们说过，Vault 模拟了一个文件系统，所有的操作都对应了一个路径，以及对应的能力，即使是 Vault 内部的核心配置信息也挂载于 sys/ 路径下。策略可以定义一个令牌对这些路径和能力的访问权限。

Vault 采用一组具有优先级的判定规则来决定最为具体的路径匹配。如果一个匹配模式被多个策略使用并能匹配上给定路径，Vault 会取其能力的并集。如果一个路径能被多个策略定义的不同的匹配模式所匹配，那么只有最高优先级的匹配会被采用。

假设对给定路径 P，存在两条策略都能够匹配，它们的路径匹配模式分别是 P1 和 P2，Vault 采用如下优先级规则：

如果 P1 中第一个 + 或是 * 出现的位置早于 P2，那么采用 P2

如果 P1 以 * 结尾，而 P2 不是，那么采用 P2

如果 P1 包含更多的 + 段，那么采用 P2

如果 P1 更短，那么采用 P2

如果 P1 得到的字典序更小，那么采用 P2

举个例子，给定两个路径：secret/* 和 secret/+/+/foo/*，由于第一个通配符的位置相同（都在 secret/ 之后），并且都以 * 结尾，而后者拥有更多的通配符段（多了两个 +/ 段），所以结果是使用 secret/* 路径模式的策略。

需要注意的是，* 与正则表达式中的同符号并不同义，Vault仅允许 * 出现在模式的末尾。

如果赋予了 list 能力，需要注意的是因为 list 操作总是作用于一个路径前缀上，所以策略定义的路径匹配模式必须使用前缀匹配（即以 * 结尾）。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

hashicorp-vault

密钥管理系统

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

hashicorp-vault

密钥管理系统

登录后参与评论

0 条评论

热度