2017-09-14 5 views
1

Essayer de trouver le meilleur moyen de bloquer toute connexion Internet à un service k8s utilisant Istio.Utilisation d'Istio pour bloquer les connexions entrantes de ANY vers un service

Quel serait le meilleur choix parmi les politiques d'Istio?

Mixer - refus ou listes Pilot - itinéraire règles - telles que l'injection de faute d'abandon (400) ou la politique de destination - tel que le circuit de rupture (connexion max 0 ???)

essayé tous les ci-dessus mais rien ne fonctionne et peu d'entre eux ne sont pas très intuitifs à configurer (et pas bien documentés).

apprécierions si un exemple de travail sera fixé

Voici un exemple pour Injecting HTTP fault policy.

destination: "ratings.default.svc.cluster.local" 
route: 
- tags: 
    version: 
httpFault: 
    abort: 
    percent: 100 
    httpStatus: 400 
httpStatus: 400 

D'abord, Istio demande un "type":

Error: Istio doesn't have configuration type , the types are destination-policy, ingress-rule, route-rule

Après avoir ajouté le type manuellement:

type: route-rule 
destination: "ratings.default.svc.cluster.local" 
route: 
- tags: 
    version: 
httpFault: 
    abort: 
    percent: 100 
    httpStatus: 400 

Il crie sur la méthode:

I0914 17:44:32.417839 1003 request.go:991] Response Body: 405: Method Not Allowed Error: the server does not allow this method on the requested resource

Merci

Répondre

0

a découvert que la route des règles de Istio appliquent uniquement lorsque les deux points de terminaison de connexion (pod client et pod serveur), sont équipés avec des Envoys.

C'est en soi quelque chose qui devrait être étudié plus avant car cela n'a aucun sens.

Le trafic provenant de l'extérieur du cluster doit en effet être contrôlé par l'entrée.

0

La méthode la plus simple devrait être d'avoir simplement l'authentification istio et aucune entrée dans votre configuration.

De cette façon, vous obtenez 2 couches de protection:

  1. vos services ne sont pas routable (pas IP externe)

et

  1. même Si le trafic Internet parvient à toucher vos services, le trafic sera rejeté car il ne fournit pas le service istio CERT/signé par votre istio CA
+0

Les deux approches ci-dessus sont bonnes pour certains environnements ou configurations. Je cherche actuellement à appliquer une technique "ad-hock" pour appliquer un bloc à la volée en utilisant un environnement déjà déployé qui ne permettra pas facilement d'ajouter de nouvelles fonctionnalités (sauf si elles sont déjà déployées). – Zvika

+0

L'approche Istio auth serait parfaite lorsque vous savez qui sont vos clients ou pour une utilisation d'activation de service. Lorsque vous souhaitez exposer largement votre service, l'authentification ne correspondra pas. – Zvika

+0

Pour exposer largement votre service, vous devez ajouter une entrée pour ceux que vous souhaitez exposer, et configurer les règles de mixage Istio sur cela pour restreindre l'accès –

2

Si vous essayez simplement de bloquer le trafic externe vers votre service, les règles de routage (injection de faute) ne sont pas correctes. Vous devriez plutôt le bloquer en ne l'exposant pas dans votre entrée. Cela dit, la raison pour laquelle vous avez eu des erreurs lors de la définition d'une règle de routage est que votre format yaml est incorrect. Quelque chose comme ceci est ce que le coammand de istioctl attend:

type: route-rule 
name: ratings-block 
spec: 
    destination: "ratings.default.svc.cluster.local" 
    route: 
    - tags: 
     version: v1 
    httpFault: 
    abort: 
     percent: 100 
     httpStatus: 400 

Voir exemples ici: https://istio.io/v-0.1/docs/tasks/request-routing.html

0

Istio a un concept d'intérieur/extérieur de maille. Chaque service à l'intérieur de mesh a un proxy sidecar, et leur trafic est soumis à des règles de routage. Tout ce qui vient de l'extérieur du mesh doit passer par Ingress. Ingress lui-même est un service de maillage (un proxy).