应用身份和访问适配器

使用 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: 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 使用 Bearer 令牌流进行保护，在该流中，传入令牌将针对特定策略进行验证。Bearer 令牌授权流期望请求包含 Authorization 头，其中包含 JWT 格式的有效访问令牌。预期的头结构为 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 应用程序，无论您使用何种编程语言和框架。遵循这种方法可确保您的应用程序具有最大的可移植性，以及在多个环境中轻松执行相同安全策略的能力。

您可以在 发布博客 中阅读有关应用身份和访问适配器的更多信息。

分享此帖子