Забезпечення політики авторизації

3 хвилин(и) перевірка сторінки

Після того, як ви додали застосунок до ambient mesh, ви можете забезпечити доступ до нього, використовуючи політики авторизації Layer 4.

Ця функція дозволяє контролювати доступ до сервісу та з сервісу на основі ідентичностей клієнтських робочих навантажень, які автоматично призначаються всім робочим навантаженням в сервісній мережі.

Забезпечення політики авторизації Layer 4

Створимо політику авторизації, яка обмежує, які сервіси можуть спілкуватися з сервісом productpage. Політика застосовується до podʼів з міткою app: productpage та дозволяє виклики тільки зі службового облікового запису cluster.local/ns/default/sa/bookinfo-gateway-istio. Це службовий обліковий запис, який використовується шлюзом Bookinfo, який ви розгорнули на попередньому кроці.

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-ztunnel
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/bookinfo-gateway-istio
EOF

Якщо ви відкриєте застосунок Bookinfo в оглядачі (http://localhost:8080/productpage), ви побачите сторінку продукту, як і раніше. Однак, якщо ви спробуєте отримати доступ до сервісу productpage з іншого службового облікового запису, ви повинні побачити помилку.

Спробуйте отримати доступ до застосунку Bookinfo з іншого клієнта в кластері:

$ kubectl apply -f @samples/curl/curl.yaml@

Оскільки pod curl використовує інший службовий обліковий запис, він не матиме доступу до сервісу productpage:

$ kubectl exec deploy/curl -- curl -s "http://productpage:9080/productpage"
command terminated with exit code 56

Забезпечення політики авторизації Layer 7

Щоб забезпечити політики Layer 7, спочатку потрібно мати waypoint proxy для простору імен. Цей проксі буде обробляти весь трафік Layer 7, що входить у простір імен.

$ istioctl waypoint apply --enroll-namespace --wait
waypoint default/waypoint applied
namespace default labeled with "istio.io/use-waypoint: waypoint"

Ви можете перевірити проксі waypoint і переконатися, що він має статус Programmed=True:

$ kubectl get gtw waypoint
NAME       CLASS            ADDRESS       PROGRAMMED   AGE
waypoint   istio-waypoint   10.96.58.95   True         42s

Додавання політики авторизації L7 явно дозволить сервісу curl надсилати GET запити до сервісу productpage, але не виконувати інші операції:

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-waypoint
  namespace: default
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/curl
    to:
    - operation:
        methods: ["GET"]
EOF

Зверніть увагу, що поле targetRefs використовується для вказання цільового сервісу для політики авторизації проксі waypoint. Розділ rules подібний до попереднього, але тепер ми додали розділ to, щоб вказати дозволену операцію.

Памʼятаєте, що наша політика L4 вказувала ztunnel дозволяти зʼєднання тільки зі шлюзу? Тепер нам потрібно оновити її, щоб дозволити зʼєднання і з waypoint.

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: productpage-ztunnel
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/bookinfo-gateway-istio
        - cluster.local/ns/default/sa/waypoint
EOF

Перевірте, чи новий проксі waypoint застосовує оновлену політику авторизації:

$ # Це призведе до помилки RBAC, оскільки ми не використовуємо операцію GET
$ kubectl exec deploy/curl -- curl -s "http://productpage:9080/productpage" -X DELETE
RBAC: access denied

$ # Це призведе до помилки RBAC, оскільки ідентичність сервісу reviews-v1 не дозволена
$ kubectl exec deploy/reviews-v1 -- curl -s http://productpage:9080/productpage
RBAC: access denied

$ # Це працює, оскільки ми явно дозволили GET запити від podʼа curl
$ kubectl exec deploy/curl -- curl -s http://productpage:9080/productpage | grep -o "<title>.*</title>"

Подальші кроки

З проксі waypoint тепер ви можете забезпечити політики Layer 7 у просторі імен. Окрім політик авторизації, ми можемо використовувати проксі waypoint для розподілу трафіку між сервісами. Це корисно для проведення canary deployments або A/B тестування.