在 Puppet 的世界中，Master 和 Agent 是靠著 SSL 認證進行認證
整個認證的交易就和我們一般 HTTP 的 SSL 申請狀況相同，Agent 就像是一般企業客戶端，而 Master 就是 SSL 憑證中心。
- 由 Agent 向 Master 發起憑證簽署需求 (CSR)
- 由 Master 依照 Agent 提供的 CSR 簽署一份 SSL 憑證提交給 Agent
- 由 Master 起的 CA 憑證底下皆信任所有簽署過的 CSR
- Master 的 CA 憑證並不需要外部憑證信任，使用 local CA 信任
整個的 SSL 的交易過程就像是我們向憑證中心交易的過程，只不過 HTTPS 是 trust internet，而 Puppet 是 trust local。
然而 Agent 交付給 Master 需要經過 Master 的同意，在前篇我們所使用的就是手動簽署的動作，但是這是一個 "自動化佈署工具" 就不該有這些人工介入的部份，所以 Puppet 除了手動簽署 (signing) 還有自動簽署 (Naive Autosigning) 和 白名單簽署 (Basic Autosigning)、限制的簽署 (Policy-based autosigning)、限制簽署 API (Policy executable API)
手動簽署的部份在前篇就已經提過了，在這邊就不再多論述。
自動簽署 (Naive Autosigning)
在自動簽署中是最不安全的簽署方式，當使用 Naive Autosigning 的話，所有的 Agent CSR 要求皆會自動同意簽署，這並不適合用在正式環境，但相對的用於測試環境是非常方便。
設定自動簽署你只需要在 puppet.conf 的 [master] 中加入 autosign = true
$ vim /etc/puppetlabs/puppet/puppet.conf
[master]
autosign = true
白名單簽署 (Basic Autosigning)
Basic Autosigning 是繼承 Naive Autosigning 的概念在加上白名單限制，你可以針對 Agent 所申請的 domain 進行白名單限制，例如 *.example.com，你可以用 autosign.conf 將這些清單寫入
$ vim /etc/puppetlabs/puppet/autosign.conf
*.example.com
ami.puppet.com
Default autosign.conf at /etc/puppetlabs/puppet/autosign.conf
對於正式環境這也不是一個好的管理方式，因為攻擊者可以偽裝要申請的憑證訊息。
限制的簽署 (Policy-based autosigning)
在 Policy-based autosigning 中你可以定義 Policy 簽署的條件，在 Agent 發出的 csr 請求中動手腳，加入一些可以提供驗證的資訊 (embedding additional data)，如 Password, token ... etc，再由 Master 觸發 autosign 所執行的 script 進行驗證，這個 scirpt 不限語言，只要 return 給 Puppet 0 or 1 就行。
Puppet 官方極力推薦使用 Policy-based autosigning 這種方式進行驗證，是目前最安全且彈性的作法，甚至可以把 Policy-based autosigning 當成一個 trigger 去做許多事件。
限制簽署 API (Policy executable API)
延伸 Policy-based autosigning 概念的作法，你也可以透過 API 進行簽署認證，但這情況小弟認為還是比較屬於客製化的部份才需要做到 API，在此篇就不再多論述，可參考
參考：
Image from SCM Puppet: from an intro to the scaling
SSL configuration: autosigning certificate requests
Orignal From: 【DevOps】Puppet 4 自動化部署 - Master 和 Agent 的認證關係
沒有留言:
張貼留言