Istio (1.6.2): ​​политика DENY в политике авторизации не работает с действующим токеном - PullRequest
Новая
       142

Istio (1.6.2): ​​политика DENY в политике авторизации не работает с действующим токеном

2 голосов
/ 09 июля 2020

Я новичок в Istio. Я реализую авторизацию с помощью JWT. Действие DENY не отражается для действительного токена JWT. Я добавил JWT Payload and Authorization Policy для справки. Я использую Kubernetes версии v1.18.3 и Istio 1.6.2. Я использую кластер на minikube.

Сначала я применил следующее правило для входного шлюза: 

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: ingress-auth-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "https://dev-n63ipah2.us.auth0.com/"
    jwksUri: "https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json"
    audiences: 
    - "http://10.97.72.213/"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: ingress-authz
 namespace: istio-system
spec:
 selector:
   matchLabels:
     istio: ingressgateway
 action: ALLOW
 rules:
  - when:
    - key: request.auth.claims[iss]
      values: ["https://dev-n63ipah2.us.auth0.com/"]

После этого я применил приведенную ниже политику для службы dex-ms-contact 

JWT Payload:
{
  "iss": "https://dev-n63ipah2.us.auth0.com/",
  "sub": "sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0@clients",
  "aud": "http://10.97.72.213/",
  "iat": 1594274641,
  "exp": 1594361041,
  "azp": "sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0",
  "gty": "client-credentials"
}

RequestAuthentication:

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: dex-ms-contact-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  jwtRules:
  - issuer: "https://dev-n63ipah2.us.auth0.com/"
    jwksUri: "https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json"
    audiences: 
    - "http://10.97.72.213/"
---
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: dex-ms-contact-require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  action: DENY
  rules:
  - when:
    - key: request.auth.claims[iss]
      values: ["https://dev-n63ipah2.us.auth0.com/"]

Политика входного шлюза работает нормально. Однако, когда я применяю политику DENY к службе dex-ms-contact, политика DENY не отражается с действительным токеном JWT. В идеале он не должен позволять мне обращаться к сервису dex-ms-contact правильно?

Какое поведение ожидается?

1 Ответ

1 голос
/ 10 июля 2020

Согласно документации istio :

Политика авторизации Istio позволяет контролировать доступ к рабочим нагрузкам в me sh.

Политика авторизации поддерживает как разрешить, так и отрицать политику. Когда политики разрешения и запрета используются для рабочей нагрузки одновременно, сначала оцениваются политики запрета. Оценка определяется по следующим правилам:

  1. Если есть какие-либо политики ОТКАЗАТЬ, соответствующие запросу, отклонить запрос.
  2. Если нет политик РАЗРЕШЕНИЯ для рабочей нагрузки, разрешить запрос.
  3. Если какая-либо из политик РАЗРЕШЕНИЯ соответствует запросу, разрешить запрос.
  4. Отклонить запрос.

Итак, принимая во внимание, что сначала оцениваются политики запрета. Ваш запрос мог быть сначала отклонен в политике рабочей нагрузки, а затем разрешен в политике шлюза, что привело к полному переопределению правила запрета.

Учитывая, что порядок оценки политик является более конкретным, c что должно быть разрешено в политике ALLOW вероятно, сделает вашу модель разрешений возможной.

Надеюсь, это поможет.

Изменить:

Согласно документации istio :

РАБОЧАЯ ЗАГРУЗКА

Бинарный файл, развернутый операторы , чтобы доставить некоторые функции приложения службы мне sh. У рабочих нагрузок есть имена, пространства имен и уникальные идентификаторы. Эти свойства доступны в конфигурации политики и телеметрии с использованием следующих атрибутов :

  • source.workload.name, source.workload.namespace, source.workload.uid
  • destination.workload.name, destination.workload.namespace, destination.workload.uid

В Kubernetes рабочая нагрузка обычно соответствует развертыванию Kubernetes, а экземпляр рабочей нагрузки соответствует отдельному поду управляемому по развертыванию.

Извините за поздний ответ, я отсутствовал некоторое время.

...