四個微服務授權認證的最佳實踐 - thenewstack

1、將授權邏輯和策略與底層微服務解耦
在授權方面，團隊可以採取的最有力的措施是將授權邏輯和政策與應用程式本身解耦，
也就是說，不要將授權邏輯硬編碼到微服務中。
這使得團隊可以在不改變應用程式編碼的情況下，輕鬆改變政策的授權編碼。

將你的授權標準化在像Open Policy Agent（OPA）這樣的工具上，它允許你在不同的服務和團隊中一致地建立和執行策略。由於OPA非常靈活，這也為你提供了廣泛的選擇，你可以選擇如何實際構建授權執行，以及在應用程式中儲存策略庫。

2、使用Sidecar強制執行以保證安全、效能和可用性
在過去，大多數授權決定都發生在閘道器處--如果開發者願意，他們仍然可以在那裡為微服務強制執行授權。然而，為了安全、效能和可用性，通常最好也為每個微服務API執行授權步驟。如前所述，在零信任架構中，每個請求在被允許之前都必須經過認證和授權。

將每個授權請求傳送到一個集中式服務是完全可能的。然而，這可能會大大增加延遲--例如，一個使用者請求可能會穿越許多服務，如果每個請求都需要額外的網路跳轉來到達集中式授權引擎，這可能會妨礙使用者體驗。

如果你使用的是OPA這樣的工具，幸運的是，你也可以把本地授權引擎和策略庫作為每個微服務的邊車執行。

3、強制執行JSON網路令牌（JWT）驗證 
為了與在零信任模式下驗證每個使用者和每個服務間請求的需要保持一致，在這些實體之間建立安全信任也是一種最佳做法。進入JSON網路令牌（JWTs）。這些訪問令牌提供了一種驗證呼叫者身份的統一方式--因為它們是 "簽名的"，由你的架構中受信任的身份伺服器（如OAuth2或OpenID Connect）簽發，你知道你可以信任與之相關的使用者ID（它們必須與與令牌相關的公鑰相匹配）。

作為獎勵，JWTs是 "自足的 "實體。它們記錄了你建立使用者訪問元素（如角色和許可權）所需的所有資料（和後設資料）--不需要對集中式服務進行外部呼叫來執行查詢。

和前面的提示一樣，你也可以用OPA完成這個步驟（驗證JWTs）。簡單地說，你可以在微服務API層面建立並強制執行需要驗證令牌的策略--例如，所有對服務A或服務B的請求必須包含一個有效的JWT。此外，你還可以包括基於上下文的授權要求--例如，使用者必須是開發人員，目前正在通話中，並且處於某個地理位置--這些都是提出請求所需要的。通過這種簡單的方式，你可以開始在你的微服務叢集中更有效地執行零信任。

4、使用RBAC和ABAC來控制終端使用者的行為
以類似的方式，使用基於角色的訪問控制（RBAC）來控制終端使用者根據他們的工作職能被授權在叢集中做什麼，也是一種最佳實踐。RBAC不僅僅是一個最佳實踐，它是應用層面授權的基礎。RBAC比僅僅獲取一個使用者名稱並評估其擁有的許可權更廣泛，它允許你將許可權分組為角色--開發人員、營銷人員、人員操作或任何其他角色。然後，你可以為該角色分配許可權，這是很容易分配或撤銷的。這是一種比以每個使用者為基礎分配許可權更簡單、更合理和可擴充套件的方式。

在這裡，你可以使用OPA這樣的工具輕鬆地執行RBAC。