[Day 06] - Vault Built-in help and Auth


Built-in help

在前幾篇的操作中,我們可以知道 vault server 會使用 path 去進行相關設定,類似在操作 filesystem。
而其中像是先前操作 AWS 的 aws/config/root 以及 database 的 mysql/config/database,是 Vault server 在這些的 secrets engine 中,已經有預先定義好特定的 path,我們必須遵守這些 path 才能順利的把設定套上去。
如果把上述的設定改到其他的 path 上, vault server 會沒辦法找到相對應的設定!

看到這邊,可能會有人覺得,蛤?那我不就要背一大堆 path ?

貼心的 vault server 跟許多的工具一樣,有著 help 的頁面來幫助大家。
具體的使用方法如下:

vault secrets enable -path=aws aws
vault path-help aws

vault secrets enable -path=awspath aws
vault path-help awspath

注意!使用 vault path-help,後面要帶的是 path 的名稱唷!

輸出的結果如下:

$ vault path-help aws

### DESCRIPTION

The AWS backend dynamically generates AWS access keys for a set of
IAM policies. The AWS access keys have a configurable lease set and
are automatically revoked at the end of the lease.

After mounting this backend, credentials to generate IAM keys must
be configured with the "root" path and policies must be written using
the "roles/" endpoints before any access keys can be generated.

### PATHS

The following paths are supported by this backend. To view help for
any of the paths below, use the help command with any route matching
the path pattern. Note that depending on the policy of your auth token,
you may or may not be able to access certain paths.

    ^config/lease$
        Configure the default lease information for generated credentials.

    ^config/root$
        Configure the root credentials that are used to manage IAM.

    ^creds/(?P<name>\w+)$
        Generate an access key pair for a specific role.

    ^roles/(?P<name>\w+)$
        Read and write IAM policies that access keys can be made for.

以上是以 root path 下去執行 path-help 的結果,如果要進一步查看各個 path 的內容,可以在 <path> 輸入需要查看的 path,像是 vault path-help aws/config/root 或是 vault path-help aws/roles/not-exist , vault server 會自行配對最適合的 help 並顯示出來。
在管理上就不需要一筆一筆背下來啦!


Authentication and Authorization

Authentication

Authentication (驗證),驗證使用者的身份。要使用 vault server 之前,一定要先經過驗證,才能進行操作。有人可能會問,可是我們之前的操作都沒說到驗證耶!那是因為 dev mode vault server 啟動的時候也一併的使用 root token 將驗證做完了。

在 vault server 裡,預設的驗證方法是 token authentication ,這一個驗證機制無法被停用,在啟動 vault server 時, vault server 會提供一組 root token ,這組 token 具有最大的權限,也是第一次登入進行初始化必備的 token。

要產生新的 token 可以執行 vault token create ,這會產生一組新的 token 出來,在不帶任參數的情況下,會在目前登入的 token 下,建立子token(child token),並繼承相同的權限

這個父子token的觀念很重要,當 父token(parent token)被註銷的時候,子token也會跟著一起被註銷,這在 token 的管理上會更簡單。

在官方的文件不建議使用 token authentication,除了 token authentication,也提供了各式各樣的驗證方式,像是 github、LDAP、AWS 等等,這個部份可以參考官網的教學進行操作唷!

Authorization

驗證完使用者的身後,接下來是 Authorization (授權),會依照使用者的身份,給予相對應的權限。
使用者的權限的大小,會看這位使用者被定義在哪個 policy 裡。
Vault server 預設會有兩個不能刪除的 policy:

  • default: 提供了基本權限的policy,並在token生成的時候,會自動套上。
  • root: 最大權限的policy。

我們可以透過新增 policy 去新增、限制使用者的權限。policy 是用 HCL 的格式寫的, policy 預設是以 deny 處理,任何沒被定義的 path 都會被限制。

path "secret/data/*" {
  capabilities = ["create", "update"]
}

path "secret/data/foo" {
  capabilities = ["read"]
}

如果我們把上方的 policy 套到 foo-deny 這個身份,使用 foo-deny 登入的使用者可以在 secret/data/ 路徑下更新或是建立任何資料,而在 secret/data/foo 下,就只能進行讀取而已。

藉由結合 authentication 跟 authorization ,控管使用者的權限,進而可以有效的控管機密資料!

Reference

#vault







你可能感興趣的文章

利用 Shell Scripts 寫一支小程式

利用 Shell Scripts 寫一支小程式

MTR04 W2 D19 第二週作業

MTR04 W2 D19 第二週作業

Git 速記

Git 速記






留言討論