作者: Dan Reed 和 Eric Slick
來源：Medium
每個網絡都有一個大問題：如何平衡安全性和易用性。通常，網絡越安全，管理和使用就越困難。相反，管理和使用的解決方案越容易，它往往越不安全。在AWS的訪問管理方面人們會遇到類似的問題，於是我們試圖用Mastermind去找到安全性和易用性之間的最佳平衡點。事實上，它是一個令人驚喜的優雅解決方案，為我們提供了兩全其美的辦法。我們將向您展示為什麼Mastermind是一個完美解決方案以及它是何如達到這個平衡點的。
簡單的集成示例
在Mastermind中，當新應用程序需要訪問AWS資源時，該應用程序只需向其源添加一個Access-Request文件，該文件定義了應用程序所需的特定AWS資源。該文件可能如下所示：
“common”部分將應用於所有環境中的部署，“prod”部分將僅應用於prod。這意味著所有環境都將對“arn：aws：s3 ::: example-app-bucket / *”進行“s3：GetObject”訪問，但除了“s3：GetObject”之外，只有prod將具有“s3：PutObject”。
這就是所有我們需要做的。我們將向您詳細地解釋如何運行Mastermind。但在此之前，先帶您瞭解一下在使用Mastermind之前網絡訪問控制是如何操作的。
“曾經的壞日子”
多年來，我們實施了多種方法來管理應用程序對AWS資源的訪問。沒有任何一個是“理想的”。安全性是最首要的需求，但我們提出的所有合理的管理方案都缺乏安全性。如果僅從安全性出發選取可行的管理方式，它們跟其他應用程序一起運行的時候或者更換環境後會變得笨重難以運行。
更糟糕的是，我們最終得到了多個解決方案，需要在組織中的多個架構內執行。於是我們意識到我們需要改變思路，尋找其他解決方案。
因此，我們開始設計一個可以替代它們的單一訪問系統。我們想要的新系統需要滿足以下特性：
1. 堅持最小特權原則，這意味著訪問應儘可能緊密地適應應用程序的要求（安全性）。
2. 取消訪問密鑰的使用，尤其是共享密鑰和長期密鑰（安全性和可管理性）。
3. 減少授予必要訪問權限所需的人工工作量（易用性和可管理性）。
4. 使軟件集成儘可能無縫銜接（易於使用）。
第一版
我們首次嘗試的解決方案是靜態訪問密鑰。這種方法的主要問題是管理和安全性。因為密鑰需要存儲和輪換，這是管理上的一個負擔。此外，開發人員可以輕鬆地重複使用密鑰，這使得記錄使用這些密鑰幾乎不可能。
我們知道如果將管理和密鑰分開，限制密鑰的使用權限，我們可以在一定程度上解決此類問題。但這會增加我們的管理費用，因為SRE需要維護應用程序和內容。換句話說，我們在解決一個問題的同時創造了另一個問題。
第二版
然後我們決定使用角色。這最終產生了與密鑰創建類似的問題，因為它也需要對管理進行大量的維護。它讓我們知道是誰在使用哪些角色，從而防止角色重用。但是，SRE仍在手動創建、分配和更新角色。也就是說，增加安全性使管理變得更加困難。整個探索過程就像一個打鼴鼠的遊戲。擊中安全性，易用性受到影響。但是保證易用性就會讓管理問題變得棘手。也許這個問題是無解的。
頓悟時刻
之後一個簡單的想法改變了這個困境。有誰會比應用程序的開發人員更瞭解應用程序所需要的訪問權限呢？既然如此，那為什麼不授權開發人員決定他們需要哪些訪問權限呢？
從那一刻，我們從才開始從正確的角度思考這個問題。如果我們可以直接地讓應用程序聲明它需要訪問哪些資源，那麼系統可以使用更適當的角色來連接這些資源。
這個想法意味著應用程序將不再需要選擇用什麼角色。開發人員只需要定義一個簡單的文件包含其開發的程序所需資源的訪問。然後，Mastermind可以找出相應的內容來連接應用程序和所需資源。這啟發了我更多的想法：我們能否將Mastermind自動化並完全消除人為干預的需要？事實證明，我們完全可以做到。
這一切是如何運作的？
我們大可以揮揮手輕鬆地說：“它就是有效。”但這不是魔術，沒有那麼簡單，所以讓我們從一個需要資源的新應用程序的角度來解釋它。
任何新應用程序請求訪問的第一步是創建訪問請求文件。如前所述，它看起來像這樣。
下一步是在部署應用程序期間發生的。在我們的例子中，我們使用Spacepods進行部署。Spacepods讀入Access-Request文件並可能加入環境信息。然後它將此數據傳遞給Mastermind。
一旦Mastermind接收到Access-Request文件的內容，它就會做三件事。 首先，它會構建訪問所請求資源的必要角色。然後，它會生成一個AWS CLI配置文件，描述他們訪問的角色和資源。生成的AWS CLI配置文件如下所示：
此AWS CLI配置文件具有“默認”部分，用於定義可以訪問所有本地資源的角色，以及應用程序請求訪問的任何遠程環境（其他AWS賬戶中的資源）的特定於環境的部分。
此時，Mastermind將AWS CLI配置文件返回給Spacepods。Spacepods然後將該文件添加到應用程序的容器設置中。因此，當應用程序轉動時，AWS CLI配置文件將被添加到容器中。
這意味著當應用程序加載AWS SDK（或任何知道此配置文件的庫）時，便可以立即獲得訪問所請求資源所需的所有權限。所有這些，都不需要應用程序或者引用角色。以下Ruby示例設置對兩個不同存儲桶的訪問。
如果未指定配置文件，則使用默認值，這意味著如果我們僅訪問容器本地的資源，則根本不需要指定配置文件。在我們請求訪問不同帳戶中的資源的情況下，我們需要指定配置文件（“prod”）。
易於管理
Mastermind的主要功能是獲取AWS資源和相應操作的列表，然後創建授予對所請求資源的訪問權限的角色。以下是關鍵部分的高級概述：
如前文所述，應用程序定義其Access-Request文件，然後使用我們自己的工具Spacepods部署應用程序。
Mastermind充當黑盒子來創建角色並將它們鏈接到應用程序。它向Spacepods返回一個AWS CLI配置文件，該文件在旋轉時插入應用程序的容器中。然後，AWS SDK使用該文件為應用程序提供對所需AWS資源的訪問權限。
所有這些自動化的過程大大減少了對管理角色和應用程序的需求。應用程序定義它想要的資源這一事實進一步簡化了管理。該應用程序索取自己所需的資源，所以，它一定是正確的。
但是，並非一切都是自動處理的。每次應用程序決定需要訪問新資源時，都會引入手動步驟。在這種情況下，Mastermind將通過Slack向相應的人發送批准請求。一旦獲得批准，SRE就會收到通知，他們會按下一個按鈕，讓Mastermind發揮其魔力。你看，整個過程真的很複雜！
等等！不僅如此，它還真的很安全！
訪問是針對每個應用程序定製的，所以只有實際使用的資源是公開的。Spacepods充當應用程序請求資源和Mastermind之間的可信中介，同時也是構建和部署應用程序容器的唯一方式，因此我們可以安全地控制構建角色和將AWS資源連接到應用程序的整個過程。
開發人員永遠不會直接接觸或瞭解AWS角色。從技術上講，他們可以找出他們的應用程序使用的角色，但這些角色在創建它們的容器之外是無用的。這是因為每個角色都是直接綁定到運行應用程序的容器。
它是真的很簡單而優雅
應用程序開發人員只需創建一個Access-Request文件即可訪問AWS資源。不涉及任何角色或密鑰。他們需要的一切都是由Mastermind通過Spacepods為他們自動生成的。幾乎消除了所有手動管理（存在一個可操作的按鍵）。而與此同時安全性不會受到影響。
這就像我們最後根除了臉上的痣一樣。 Mastermind是一個真正意義上的簡單、優雅和安全的AWS訪問管理解決方案。
最後，感謝瑞吉斯威爾遜校正這篇文章的初稿。
