如何在 AWS S3 存儲桶中自動化訪問權限編排

多年前，當帶有大型文件系統的本地 Unix 服務器流行時，公司正在構建廣泛的文件夾管理規則和策略，以管理不同人員對不同文件夾的訪問權限。

通常，一個組織的平台服務於具有完全不同的興趣、機密級別限製或內容定義的不同用戶組。 對於全球組織，這甚至可能意味著根據位置分離內容，基本上是在屬於不同國家的用戶之間分離內容。

其他典型示例可能包括：

• 開發、測試和生產環境之間的數據分離
• 銷售內容無法為廣大受眾所訪問
• 無法從其他地區看到或訪問的特定國家/地區的立法內容
• 與項目相關的內容，其中“領導力數據”僅提供給有限的人群等。

這樣的例子可能有無窮無盡的清單。 關鍵是總是需要在平台提供訪問權限的所有用戶之間協調對文件和數據的訪問權限。

對於本地解決方案，這是一項例行任務。 文件系統的管理員只是設置了一些規則，使用了一個選擇的工具，然後人們被映射到用戶組，用戶組被映射到他們應該能夠訪問的文件夾列表或掛載點。 在此過程中，訪問級別被定義為只讀或讀寫訪問。

現在看看 AWS 雲平台，很明顯期望人們對內容訪問限制有類似的要求。 但是現在，這個問題的解決方案必須有所不同。 文件不再存在於 Unix 服務器上，而是存在於雲中（不僅整個組織甚至整個世界都可能訪問），並且內容不再存儲在文件夾中，而是存儲在 S3 存儲桶中。

下面描述的是解決此問題的替代方法。 它建立在我為具體項目設計此類解決方案時的真實經驗之上。

簡單但非常手動的方法

在沒有任何自動化的情況下解決此問題的一種方法相對簡單明了：

• 為每個不同的人群創建一個新桶。
• 分配對存儲桶的訪問權限，以便只有該特定組才能訪問 S3 存儲桶。

如果要求採用非常簡單和快速的解決方案，這當然是可能的。 但是，需要注意一些限制。

默認情況下，一個 AWS 賬戶下最多只能創建 100 個 S3 存儲桶。 通過向 AWS 票證提交服務限制增加，可以將此限制擴展到 1000。 如果這些限制不是您的特定實施案例所擔心的，那麼您可以讓每個不同的域用戶在單獨的 S3 存儲桶上操作，然後收工。

如果某些人具有跨職能職責，或者只是某些人需要同時訪問更多域的內容，則可能會出現問題。 例如：

• 數據分析師評估幾個不同領域、地區等的數據內容。
• 測試團隊共享服務於不同開發團隊的服務。
• 報告用戶需要在同一區域內的不同國家之上建立儀表板分析。

正如您可能想像的那樣，這個列表可以再次像您想像的那樣增長，並且組織的需求可以產生各種用例。

此列表變得越複雜，將需要更複雜的訪問權限編排來授予所有這些不同的組對組織中不同 S3 存儲桶的不同訪問權限。 將需要額外的工具，甚至可能需要專門的資源（管理員）來維護訪問權限列表並在任何更改請求時更新它們（這將非常頻繁，特別是如果組織很大）。

那麼，如何以更有條理和自動化的方式實現同樣的事情呢？

為桶引入標籤

如果每個域的存儲桶方法不起作用，任何其他解決方案最終都會為更多用戶組共享存儲桶。 在這種情況下，有必要在某些易於動態更改或更新的區域構建分配訪問權限的整個邏輯。

實現這一目標的方法之一是在 S3 存儲桶上使用標籤。 建議在任何情況下都使用這些標籤（如果只是為了更輕鬆地進行計費分類）。 但是，將來可以隨時更改任何存儲桶的標籤。

如果整個邏輯是基於桶標籤構建的，而後面的其餘部分是依賴於標籤值的配置，那麼動態屬性是有保證的，因為只需更新標籤值就可以重新定義桶的用途。

使用什麼樣的標籤來完成這項工作？

這取決於您的具體用例。 例如：

• 可能需要將每個環境類型的存儲桶分開。 因此，在這種情況下，其中一個標籤名稱應類似於“ENV”，並可能具有“DEV”、“TEST”、“PROD”等值。
• 也許您想根據國家/地區將團隊分開。 在這種情況下，另一個標籤將是“COUNTRY”並為某個國家/地區名稱賦值。
• 或者您可能希望根據用戶所屬的職能部門將用戶分開，例如業務分析師、數據倉庫用戶、數據科學家等。因此您創建一個名為“USER_TYPE”和相應值的標籤。
• 另一種選擇可能是您希望為他們需要使用的特定用戶組明確定義一個固定的文件夾結構（以免創建他們自己的文件夾混亂並隨著時間的推移迷失在那裡）。 您可以使用標籤再次執行此操作，您可以在其中指定幾個工作目錄，例如：“data/import”、“data/processed”、“data/error”等。

理想情況下，您希望定義標籤，以便它們可以邏輯組合併使它們在存儲桶上形成一個完整的文件夾結構。

例如，您可以組合上述示例中的以下標籤，為來自不同國家/地區的不同類型的用戶構建專用文件夾結構，並預定義他們將使用的導入文件夾：

• /<ENV>/<USER_TYPE>/<COUNTRY>/<UPLOAD>

只需更改<ENV>值，即可重新定義標籤的用途（是否分配給測試環境ecosystem、dev、prod等）

這將使許多不同的用戶能夠使用同一個桶。 存儲桶不明確支持文件夾，但它們支持“標籤”。 這些標籤最終像子文件夾一樣工作，因為用戶需要通過一系列標籤才能訪問他們的數據（就像他們對子文件夾所做的那樣）。

創建動態策略並在內部映射存儲桶標籤

以某種可用形式定義標籤後，下一步是構建將使用標籤的 S3 存儲桶策略。

如果策略使用標籤名稱，則您正在創建稱為“動態策略”的東西。 這基本上意味著您的策略對於具有策略在表單或占位符中引用的不同標籤值的存儲桶會有不同的行為。

此步驟顯然涉及動態策略的一些自定義編碼，但您可以使用 Amazon AWS 策略編輯器工具簡化此步驟，它將指導您完成整個過程。

在策略本身中，您需要編寫應用於存儲桶的具體訪問權限以及此類權限的訪問級別（讀、寫）。 該邏輯將讀取存儲桶上的標籤並將在存儲桶上構建文件夾結構（根據標籤創建標籤）。 根據標籤的具體值，將創建子文件夾，並沿線分配所需的訪問權限。

這種動態策略的好處是您可以只創建一個動態策略，然後將完全相同的動態策略分配給許多存儲桶。 對於具有不同標籤值的存儲桶，此策略的行為會有所不同，但它始終符合您對具有此類標籤值的存儲桶的期望。

這是一種以有組織、集中的方式為大量存儲桶管理訪問權限分配的真正有效方法，其中期望每個存儲桶都遵循一些預先商定的模板結構，並將由您的用戶在其中使用整個組織。

自動化新實體的入職

在定義動態策略並將它們分配給現有存儲桶後，用戶可以開始使用相同的存儲桶，而不會出現來自不同組的用戶無法訪問位於他們沒有的文件夾結構下的內容（存儲在同一存儲桶中）的風險使用權。

此外，對於一些具有更廣泛訪問權限的用戶組，很容易接觸到數據，因為它們都存儲在同一個存儲桶中。

最後一步是讓新用戶、新桶甚至新標籤的入職盡可能簡單。 這導致了另一種自定義編碼，但是，它不需要過於復雜，假設您的入職流程有一些非常明確的規則，可以用簡單、直接的算法邏輯封裝（至少您可以通過這種方式證明您的過程有一定的邏輯，並且不是以過於混亂的方式完成的）。

這可以像通過 AWS CLI 命令創建可執行腳本一樣簡單，其中包含成功將新實體載入平台所需的參數。 它甚至可以是一系列 CLI 腳本，可以按特定順序執行，例如：

• create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
• create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
• update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
• create_user_group(<user_type>,<country>,<env>)
• 等等

你明白了。

專業提示

如果您願意，可以使用一個 Pro Tip，它可以很容易地應用在上面的上面。

動態策略不僅可以用於分配文件夾位置的訪問權限，還可以自動分配存儲桶和用戶組的服務權限！

所需要做的就是擴展存儲桶上的標籤列表，然後添加動態策略訪問權限，以便為具體的用戶組使用特定的服務。

例如，可能有一些用戶組也需要訪問特定的數據庫集群服務器。 這無疑可以通過利用存儲桶任務的動態策略來實現，如果對服務的訪問是由基於角色的方法驅動的，則更是如此。 只需向動態策略代碼添加一個部分，該部分將處理有關數據庫集群規範的標籤，並將策略訪問權限直接分配給特定的數據庫集群和用戶組。

這樣，新用戶組的入職將僅通過此單一動態策略執行。 此外，由於它是動態的，因此可以重複使用相同的策略來引導許多不同的用戶組（期望遵循相同的模板但不一定是相同的服務）。

您還可以查看這些 AWS S3 命令來管理存儲桶和數據。