Istio AuthorizationPolicy 在使用 Oauth2-Proxy 和 Dex 登录流程后返回 403

问题描述 投票：0回答：1

我尝试将 OAuth2-Proxy 与 Istio AuthorizationPolicy 结合使用来处理在 AKS 上运行的应用程序的登录和授权。就目前情况而言，当我在浏览器中访问应用程序端点 (httpbin.example.com) 时，我成功重定向到 Dex，并且我可以使用 Dex 登录（使用本地数据库用户名/密码），然后重定向回到我的应用程序。但此时我收到 403 错误，读取“RBAC：访问被拒绝”。我相信该消息来自 Istio AuthorizationPolicy。

Istio版本：1.18.2

就目前情况而言，我的授权策略如下所示：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: oauth-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: CUSTOM
  provider:
    name: "oauth2-proxy"
  rules:
  # The rules specify when to trigger the external authorizer.
  - to:
    - operation:
        hosts:
        - "httpbin.example.com"

我的自定义提供程序的配置如下所示：

meshConfig:
    extensionProviders:
    - name: "oauth2-proxy"
      envoyExtAuthzHttp:
        service: "oauth2-proxy.demo.svc.cluster.local"
        port: "80"
        headersToDownstreamOnDeny:
          - content-type
          - set-cookie
        headersToUpstreamOnAllow:
          - authorization
          - cookie
          - path
          - x-auth-request-access-token
          - x-forwarded-access-token
        includeHeadersInCheck:
          - "cookie"
          - "x-forwarded-access-token"
          - "x-forwarded-user"
          - "x-forwarded-email"
          - "authorization"
          - "x-forwarded-proto"
          - "proxy-authorization"
          - "user-agent"
          - "x-forwarded-host"
          - "from"
          - "x-forwarded-for"
          - "accept"
        includeAdditionalHeadersInCheck:
          authorization: '%REQ(x-auth-request-access-token)%'

我的 OAuth2-Proxy 配置如下所示：

# Oauth client configuration specifics
config:
  # OAuth client ID

  clientID: "oauth2-proxy"
  # OAuth client secret
  clientSecret: "ZXhhbXBsZS1hcHAtc2VjcmV0"

  cookieSecure: true
  cookieSecret: "b311562c684c75e497b4fb3f08c3deea"
  # The name of the cookie that oauth2-proxy will create
  # If left empty, it will default to the release name
  cookieName: "_oauth2_proxy"

  configFile: |-
    email_domains = [ "*" ]
    upstreams = [ "static://200" ]
    provider = "oidc"
    cookie_refresh = "5m"
    cookie_expire = "4h"
    cookie_domains = [ "httpbin.example.com" ]
    cookie_samesite = "lax"
    set_xauthrequest = true
    set_authorization_header = true
    pass_authorization_header = true
    pass_host_header = true
    pass_access_token = true
    skip_jwt_bearer_tokens = true
    reverse_proxy = true
    skip_provider_button = true
    http_address = "0.0.0.0:4180"
    silence_ping_logging = true
    oidc_issuer_url = "http://dex.example.com"
    scope = "openid"
    oidc_email_claim = "sub"
    real_client_ip_header = "X-Forwarded-For"

我在尝试后在 Dex 日志中看到了这一点，这表明在 Dex 至少返回之前一切都很好：

time="2023-11-06T18:10:02Z" level=info msg="login successful: connector \"local\", username=\"admin\", preferred_username=\"\", email=\"[email protected]\", groups=[]"

然后我在 OAuth2-Proxy 日志中得到这个：

[2023/11/06 18:09:51] [oauthproxy.go:970] No valid authentication in request. Initiating login.
10.215.1.230 - 7e0f3851-d605-4e71-b9e1-335dabad9397 - - [2023/11/06 18:09:51] httpbin.example.com GET - "/" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" 302 270 0.000
10.215.1.230 - 18df84c5-2636-4f0d-9278-51035f8db86c - CiQwOGE4Njg0Yi1kYjg4LTRiNzMtOTBhOS0zY2QxNjYxZjU0NjYSBWxvY2Fs [2023/11/06 18:10:02] [AuthSuccess] Authenticated via OAuth2: Session{email:CiQwOGE4Njg0Yi1kYjg4LTRiNzMtOTBhOS0zY2QxNjYxZjU0NjYSBWxvY2Fs user:CiQwOGE4Njg0Yi1kYjg4LTRiNzMtOTBhOS0zY2QxNjYxZjU0NjYSBWxvY2Fs PreferredUsername: token:true id_token:true created:2023-11-06 18:10:02.356686277 +0000 UTC m=+2538.147613649 expires:2023-11-07 18:10:01.353689544 +0000 UTC m=+88937.144616916}
10.215.1.230 - 18df84c5-2636-4f0d-9278-51035f8db86c - - [2023/11/06 18:10:02] httpbin.example.com GET - "/oauth2/callback?code=nomx6zwp4e2owq6ys6i26yji5&state=EhrfRhvb9g2zQfB1lGanyMaGJejNmegAo9Y_ejeAenA%3A%2F" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" 302 24 0.040
10.215.1.230 - 64574381-e3e1-486c-864c-f6a708b94fc6 - CiQwOGE4Njg0Yi1kYjg4LTRiNzMtOTBhOS0zY2QxNjYxZjU0NjYSBWxvY2Fs [2023/11/06 18:10:02] httpbin.example.com GET static://200 "/" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" 200 13 0.000
10.215.1.230 - ecfb0cb8-bf41-4362-b914-46ecf5820de7 - CiQwOGE4Njg0Yi1kYjg4LTRiNzMtOTBhOS0zY2QxNjYxZjU0NjYSBWxvY2Fs [2023/11/06 18:10:02] httpbin.example.com GET static://200 "/favicon.ico" HTTP/1.1 "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" 200 13 0.000

阅读 [AuthSuccess] 通过 OAuth2 进行身份验证： 会让我相信 OAuth2-Proxy 一切都很好，但也许我在这里缺少一些东西。

httpbin pod 的 envoy-proxy 日志乍一看似乎不包含任何相关内容：

2023-11-06T17:27:32.275893Z info    JWT policy is third-party-jwt
2023-11-06T17:27:32.275902Z info    using credential fetcher of JWT type in cluster.local trust domain
2023-11-06T17:27:32.276032Z info    platform detected is Azure
2023-11-06T17:27:32.285100Z warn    HTTP request unsuccessful with status: 400 Bad Request
2023-11-06T17:27:32.300832Z info    Workload SDS socket not found. Starting Istio SDS Server
2023-11-06T17:27:32.300859Z info    CA Endpoint istiod.istio-system.svc:15012, provider Citadel
2023-11-06T17:27:32.300877Z info    Using CA istiod.istio-system.svc:15012 cert with certs: var/run/secrets/istio/root-cert.pem
2023-11-06T17:27:32.301010Z info    Opening status port 15020
2023-11-06T17:27:32.317004Z info    ads All caches have been synced up in 46.961061ms, marking server ready
2023-11-06T17:27:32.317243Z info    xdsproxy    Initializing with upstream address "istiod.istio-system.svc:15012" and cluster "Kubernetes"
2023-11-06T17:27:32.317285Z info    sds Starting SDS grpc server
2023-11-06T17:27:32.317672Z info    starting Http service at 127.0.0.1:15004
2023-11-06T17:27:32.318984Z info    Pilot SAN: [istiod.istio-system.svc]
2023-11-06T17:27:32.319990Z info    Starting proxy agent
2023-11-06T17:27:32.320018Z info    starting
2023-11-06T17:27:32.320043Z info    Envoy command: [-c etc/istio/proxy/envoy-rev.json --drain-time-s 45 --drain-strategy immediate --local-address-ip-version v4 --file-flush-interval-msec 1000 --disable-hot-restart --allow-unknown-static-fields --log-format %Y-%m-%dT%T.%fZ   %l  envoy %n %g:%#  %v  thread=%t -l warning --component-log-level misc:error --concurrency 16]
2023-11-06T17:27:32.427876Z info    xdsproxy    connected to upstream XDS server: istiod.istio-system.svc:15012
2023-11-06T17:27:32.457010Z info    ads ADS: new connection for node:httpbin-7987fb4cc7-7vr9x.demo-1
2023-11-06T17:27:32.457262Z info    ads ADS: new connection for node:httpbin-7987fb4cc7-7vr9x.demo-2
2023-11-06T17:27:32.523788Z info    cache   generated new workload certificate  latency=206.479426ms ttl=23h59m59.476221912s
2023-11-06T17:27:32.523823Z info    cache   Root cert has changed, start rotating root cert
2023-11-06T17:27:32.523840Z info    ads XDS: Incremental Pushing:0 ConnectedEndpoints:2 Version:
2023-11-06T17:27:32.523888Z info    cache   returned workload trust anchor from cache   ttl=23h59m59.476113611s
2023-11-06T17:27:32.523920Z info    cache   returned workload certificate from cache    ttl=23h59m59.47608181s
2023-11-06T17:27:32.524062Z info    cache   returned workload trust anchor from cache   ttl=23h59m59.475948309s
2023-11-06T17:27:32.524200Z info    ads SDS: PUSH request for node:httpbin-7987fb4cc7-7vr9x.demo resources:1 size:4.0kB resource:default
2023-11-06T17:27:32.524272Z info    ads SDS: PUSH request for node:httpbin-7987fb4cc7-7vr9x.demo resources:1 size:1.1kB resource:ROOTCA
2023-11-06T17:27:32.524358Z info    cache   returned workload trust anchor from cache   ttl=23h59m59.475645506s
2023-11-06T17:27:33.858345Z info    Readiness succeeded in 1.594680949s
2023-11-06T17:27:33.858740Z info    Envoy proxy is ready
2023-11-06T17:55:26.183500Z info    xdsproxy    connected to upstream XDS server: istiod.istio-system.svc:15012

同样，我在 Ingress Gateway 的代理日志中也没有看到任何看起来很奇怪的内容。没有 403 错误或“rbac_acces_denied”之类的东西。乍一看，似乎一切都成功了。但我的浏览器看到的是 403“RBAC 访问被拒绝”消息。

2023-11-07T18:01:45.015545Z info    Readiness succeeded in 505.545447ms
2023-11-07T18:01:45.015936Z info    Envoy proxy is ready
[2023-11-07T18:01:45.257Z] "GET /.well-known/openid-configuration HTTP/1.1" 200 - via_upstream - "-" 0 1135 14 14 "-" "Go-http-client/1.1" "d8108d75-c05a-40a7-aa0e-6f2fffb483c8" "dex.example.com" "10.215.1.235:80" PassthroughCluster 172.17.2.72:37518 10.215.1.235:80 172.17.2.72:55152 - allow_any
[2023-11-07T18:02:21.416Z] "GET / HTTP/1.1" 302 - via_upstream - "-" 0 270 1 0 "10.215.1.230,172.17.3.24" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" "c7dbc03c-cc6c-47f1-bed2-3bac1d40b544" "httpbin.example.com" "172.17.2.72:4180" inbound|4180|| 127.0.0.6:46533 172.17.2.72:4180 172.17.3.24:0 outbound_.80_._.oauth2-proxy.demo.svc.cluster.local default
[2023-11-07T18:02:49.886Z] "POST /token HTTP/1.1" 200 - via_upstream - "-" 127 1489 33 33 "-" "Go-http-client/1.1" "cd49734e-0ff8-4f0d-a884-dc86ab62ec11" "dex.example.com" "10.215.1.235:80" PassthroughCluster 172.17.2.72:37518 10.215.1.235:80 172.17.2.72:55152 - allow_any
[2023-11-07T18:02:49.921Z] "GET /keys HTTP/1.1" 200 - via_upstream - "-" 0 525 3 3 "-" "Go-http-client/1.1" "98c0b3db-c7a0-418b-a1d6-3d55ce5cedb9" "dex.example.com" "10.215.1.235:80" PassthroughCluster 172.17.2.72:37518 10.215.1.235:80 172.17.2.72:55152 - allow_any
[2023-11-07T18:02:49.925Z] "GET /userinfo HTTP/1.1" 200 - via_upstream - "-" 0 191 2 2 "-" "Go-http-client/1.1" "32729787-c856-4ff0-9519-32588a973288" "dex.example.com" "10.215.1.235:80" PassthroughCluster 172.17.2.72:37518 10.215.1.235:80 172.17.2.72:55152 - allow_any
[2023-11-07T18:02:49.885Z] "GET /oauth2/callback?code=lt6gnuhpx4enqsla2yvbwflv4&state=1XRICtrxCimKRC7ukPCSNLB6abHVAE1s0JPtmb2b4do%3A%2F HTTP/1.1" 302 - via_upstream - "-" 0 24 42 42 "10.215.1.230,172.17.3.24" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" "b31ee817-8c36-4d48-bd88-6e46ce232407" "httpbin.example.com" "172.17.2.72:4180" inbound|4180|| 127.0.0.6:46533 172.17.2.72:4180 172.17.3.24:0 outbound_.80_._.oauth2-proxy.demo.svc.cluster.local default
[2023-11-07T18:02:49.949Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 13 0 0 "10.215.1.230,172.17.3.24" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36" "5f4ed413-772c-49cd-93e2-0fc6f98b96a3" "httpbin.example.com" "172.17.2.72:4180" inbound|4180|| 127.0.0.6:46533 172.17.2.72:4180 172.17.3.24:0 outbound_.80_._.oauth2-proxy.demo.svc.cluster.local default

我现在已经走进了死胡同。有人对进一步调试/实验有任何想法或想法吗？

编辑：

我做的另一件事是部署默认的 sample ext auth 提供程序并配置它，并放置一个 AuthorizationPolicy 来使用它来控制对 httpbin pod 的访问。在这种情况下，一切正常。如果我省略允许访问的神奇标头，我会返回 403，但如果我包含该标头，我就可以访问 pod。因此，一般意义上的 AuthorizationPolicies 似乎正在发挥作用，并且不知何故，我在流程结束时从 OAuth2-Proxy 返回的信息并不是 AuthorizationPolicy 所期望的“成功”案例。

oauth-2.0 authorization openid-connect istio rbac
1个回答
0
投票

解决了。在这种特定情况下，问题似乎与将两个 AuthorizationPolicy 对象绑定到同一命名空间有关，并且以一种不起作用的方式发生冲突。事实证明，第二个 AuthorizationPolicy 是我在完成一些随机教程时作为实验而添加的内容，实际上根本不需要。将其从部署中删除后，一切都按预期运行。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.