應用程式身分與存取適配器

使用 Istio 來保護多雲 Kubernetes 應用程式，無需任何程式碼變更。

2019 年 9 月 18 日| 作者：Anton Aleksandrov - IBM

如果您在 Kubernetes 上執行容器化的應用程式，可以使用應用程式身分與存取適配器，以抽象化的安全層級獲益，無需任何程式碼變更或重新部署。

無論您的運算環境是基於單一雲端供應商、多個雲端供應商的組合，還是遵循混合雲方法，擁有集中的身分管理可以幫助您保留現有的基礎設施並避免供應商鎖定。

透過 應用程式身分與存取適配器，您可以使用任何 OAuth2/OIDC 供應商：IBM Cloud App ID、Auth0、Okta、Ping Identity、AWS Cognito、Azure AD B2C 等。身份驗證和授權策略可以在所有環境中以簡化的方式應用，包括前端和後端應用程式，所有這些都無需程式碼變更或重新部署。

了解 Istio 和適配器

Istio 是一個開源服務網格，可透明地覆蓋在分散式應用程式上，並與 Kubernetes 無縫整合。為了降低部署的複雜性，Istio 提供了對整個服務網格的行為洞察和操作控制。有關更多詳細資訊，請參閱Istio 架構。

Istio 使用 Envoy 代理 sidecar 來協調服務網格中所有 Pod 的入站和出站流量。 Istio 從 Envoy sidecar 中提取遙測數據，並將其發送到 Mixer，Mixer 是負責收集遙測數據和執行策略的 Istio 組件。

應用程式身分與存取適配器透過分析服務網格中的遙測數據（屬性）來擴展 Mixer 的功能，對照各種存取控制策略進行分析。存取控制策略可以連結到特定的 Kubernetes 服務，並且可以針對特定服務端點進行微調。有關策略和遙測數據的更多資訊，請參閱 Istio 文件。

當 應用程式身分與存取適配器 與 Istio 結合使用時，它可以為多雲架構提供可擴展、整合的身分和存取解決方案，而無需任何自訂應用程式程式碼變更。

安裝

可以使用 Helm 直接從 github.com 儲存庫安裝應用程式身分與存取適配器

$ helm repo add appidentityandaccessadapter https://raw.githubusercontent.com/ibm-cloud-security/app-identity-and-access-adapter/master/helm/appidentityandaccessadapter
$ helm install --name appidentityandaccessadapter appidentityandaccessadapter/appidentityandaccessadapter

或者，您可以複製儲存庫並在本地安裝 Helm 圖表

$ git clone git@github.com:ibm-cloud-security/app-identity-and-access-adapter.git
$ helm install ./helm/appidentityandaccessadapter --name appidentityandaccessadapter.

保護 Web 應用程式

Web 應用程式最常透過稱為 authorization_code 的 OpenID Connect (OIDC) 工作流程來保護。當偵測到未經過身份驗證/未經授權的使用者時，他們會自動重新導向到您選擇的身分服務，並顯示身份驗證頁面。當身份驗證完成時，瀏覽器會重新導向回由適配器攔截的隱式 /oidc/callback 端點。此時，適配器會從身分服務取得存取權和身分權杖，然後將使用者重新導向回 Web 應用程式中他們最初請求的 URL。

身份驗證狀態和權杖由適配器維護。由適配器處理的每個請求都將包含 Authorization 標頭，其中包含以下格式的存取權和身分權杖：Authorization: Bearer <access_token> <id_token>

開發人員可以利用這些權杖來調整應用程式體驗，例如顯示使用者名稱、根據使用者角色調整 UI 等。

為了終止經過身份驗證的工作階段並清除權杖（也稱為使用者登出），只需將瀏覽器重新導向到受保護服務下的 /oidc/logout 端點，例如，如果您從 https://example.com/myapp 提供應用程式，則將使用者重新導向到 https://example.com/myapp/oidc/logout

每當存取權杖過期時，將使用重新整理權杖自動獲取新的存取權和身分權杖，而無需使用者重新進行身份驗證。如果配置的身分提供者傳回重新整理權杖，則該權杖會由適配器保存，並用於在舊權杖過期時檢索新的存取權和身分權杖。

套用 Web 應用程式保護

保護 Web 應用程式需要建立兩種資源類型 - 使用 OidcConfig 資源定義各種 OIDC 提供者，以及使用 Policy 資源定義 Web 應用程式保護策略。

apiVersion: "security.cloud.ibm.com/v1"
kind: OidcConfig
metadata:
    name: my-oidc-provider-config
    namespace: sample-namespace
spec:
    discoveryUrl: <discovery-url-from-oidc-provider>
    clientId: <client-id-from-oidc-provider>
    clientSecretRef:
        name: <kubernetes-secret-name>
        key: <kubernetes-secret-key>

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
    name: my-sample-web-policy
    namespace: sample-namespace
spec:
    targets:
    - serviceName: <kubernetes-service-name-to-protect>
        paths:
        - prefix: /webapp
            method: ALL
            policies:
            - policyType: oidc
                config: my-oidc-provider-config
                rules: // optional
                - claim: iss
                    match: ALL
                    source: access_token
                    values:
                    - <expected-issuer-id>
                - claim: scope
                    match: ALL
                    source: access_token
                    values:
                    - openid

閱讀更多關於保護 Web 應用程式的資訊

保護後端應用程式和 API

後端應用程式和 API 使用持有人權杖流程來保護，其中傳入的權杖會根據特定策略進行驗證。持有人權杖授權流程預期請求包含帶有有效 JWT 格式存取權杖的 Authorization 標頭。預期的標頭結構為 Authorization: Bearer {access_token}。如果權杖成功通過驗證，請求將轉發到請求的服務。如果權杖驗證失敗，則會將 HTTP 401 返回給用戶端，其中包含存取 API 所需的範圍清單。

套用後端應用程式和 API 保護

保護後端應用程式和 API 需要建立兩種資源類型 - 使用 JwtConfig 資源定義各種 JWT 提供者，以及使用 Policy 資源定義後端應用程式保護策略。

apiVersion: "security.cloud.ibm.com/v1"
kind: JwtConfig
metadata:
    name: my-jwt-config
    namespace: sample-namespace
spec:
    jwksUrl: <the-jwks-url>

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
    name: my-sample-backend-policy
    namespace: sample-namespace
spec:
    targets:
    - serviceName: <kubernetes-service-name-to-protect>
        paths:
        - prefix: /api/files
            method: ALL
            policies:
            - policyType: jwt
                config: my-oidc-provider-config
                rules: // optional
                - claim: iss
                    match: ALL
                    source: access_token
                    values:
                    - <expected-issuer-id>
                - claim: scope
                    match: ALL
                    source: access_token
                    values:
                    - files.read
                    - files.write

閱讀更多關於保護後端應用程式的資訊

已知限制

在撰寫此部落格時，應用程式身分與存取適配器有兩個已知的限制

總結

當採用多雲策略時，隨著環境的成長和多樣化，安全性可能會變得複雜。雖然雲端供應商提供協議和工具來確保其產品的安全性，但開發團隊仍然負責應用程式層級的安全性，例如使用 OAuth2 進行 API 存取控制、使用流量加密防禦中間人攻擊，以及為服務存取控制提供相互 TLS。但是，這在多雲環境中變得複雜，因為您可能需要單獨為每個服務定義這些安全性詳細資訊。透過適當的安全協議，可以緩解那些外部和內部威脅。

開發團隊花費時間使其服務可以移植到不同的雲端供應商，同樣地，所使用的安全性應該是靈活的，而不是依賴於基礎設施。

無論您使用哪種程式語言和框架，Istio 和應用程式身分與存取適配器都可以讓您保護 Kubernetes 應用程式，而絕對無需任何程式碼變更或重新部署。遵循這種方法可確保應用程式的最大可移植性，並且能夠輕鬆地在多個環境中強制執行相同的安全策略。

您可以在發布部落格中閱讀更多關於應用程式身分與存取適配器的資訊。

分享此文章