RBAC Fails closed if service related to envoyExtAuthHttp is deleted

Hi folks,

I’ve got an issue that may be a config I can change somewhere but I’m not really sure where to start.

I’ve added a custom provider for securing some resources in my cluster with oauth2-proxy. The config is as follows in the istio configmap under mesh

 extensionProviders:
      - envoyExtAuthzHttp:
          headersToDownstreamOnDeny:
          - content-type
          - set-cookie
          headersToUpstreamOnAllow:
          - authorization
          - path
          - cookie
          - x-auth-request-access-token
          - x-auth-request-user
          - x-auth-request-email
          includeAdditionalHeadersInCheck:
            X-Auth-Request-Redirect: '%REQ(x-forwarded-proto)%://%REQ(:authority)%%REQ(:path)%'
          includeHeadersInCheck:
          - authorization
          - cookie
          port: 80
          service: oauth2-proxy.oauth2-proxy.svc.cluster.local
          timeout: 5s
        name: oauth2-proxy

The issue is that if someone goes in and deletes the service oauth2-proxy in the oauth2-proxy namespace all ingress via Istio is blocked with the error “RBAC: access denied”. This is a big deal as while we try to do everything IaaC I can’t prevent anyone from accidentally deleting that service resource. Also if someone fat fingers the name of the provider in an AuthorizationPolicy this causes the same issue.

Being as this is the only thing we use RBAC wise is there some way fail open if there is a config issue such as the service not existing in the mesh config or an incorrect provider listed in an AuthorizationPolicy instead of failing closed and preventing all my traffic from being routed?

From security perspective, access control is always fail close instead of fail open. But you can specify “rules” when the CUSTOM access control is applied in AuthorizationPolicy, e.g., you probably want to allow some actions even if the external authorization server is down.