Service Mesh (ASM) permet d'intégrer un service d'autorisation personnalisé au flux d'autorisation d'un maillage via les protocoles HTTP ou gRPC. Cette rubrique explique comment développer un service d'autorisation personnalisé basé sur HTTP qu'un proxy de maillage appelle pour décider si une requête est autorisée.
Contexte
Service Mesh (ASM) authentifie l'identité d'une requête avant l'application des règles d'autorisation :
Requêtes arrivant à une passerelle : configurez l'authentification JWT (RequestAuthentication) sur la passerelle pour authentifier l'identité des requêtes.
Requêtes internes au maillage : les certificats mTLS émis par le maillage authentifient par défaut les identités des requêtes.
Une fois l'identité d'une requête confirmée, utilisez une politique d'autorisation (AuthorizationPolicy) pour restreindre son comportement. Outre ces fonctionnalités standard, ASM prend en charge l'intégration d'un service d'autorisation personnalisé qui décide d'autoriser ou non une requête.
Fonctionnement
Lors de l'intégration d'un service d'autorisation personnalisé basé sur HTTP, le proxy de maillage (passerelle ou sidecar) complète une requête d'autorisation HTTP avec les informations de la requête reçue. Le proxy envoie ensuite cette requête au service d'autorisation personnalisé, qui décide de l'autoriser ou non.
Le code d'état renvoyé par le service d'autorisation personnalisé détermine le résultat :
Un code d'état 200 indique que la requête a passé la vérification et est autorisée.
Un code d'état 5xx indique une anomalie du service d'autorisation personnalisé. Dans ce cas, la requête est autorisée ou refusée selon votre configuration.
Tout autre code d'état indique que la requête a échoué à la vérification et est refusée.
Développer le service d'autorisation personnalisé basé sur HTTP
ASM est compatible avec le maillage de services Istio open source. La communauté Istio fournit une implémentation exemple de service d'autorisation personnalisé. Cet exemple implémente des services d'autorisation personnalisés pour les protocoles HTTP et gRPC. L'extrait suivant présente la logique HTTP, située dans la fonction ServeHTTP :
// ServeHTTP implements the HTTP check request.
func (s *ExtAuthzServer) ServeHTTP(response http.ResponseWriter, request *http.Request) {
body, err := io.ReadAll(request.Body)
if err != nil {
log.Printf("[HTTP] read body failed: %v", err)
}
l := fmt.Sprintf("%s %s%s, headers: %v, body: [%s]\n", request.Method, request.Host, request.URL, request.Header, returnIfNotTooLong(string(body)))
if allowedValue == request.Header.Get(checkHeader) {
log.Printf("[HTTP][allowed]: %s", l)
response.Header().Set(resultHeader, resultAllowed)
response.Header().Set(overrideHeader, request.Header.Get(overrideHeader))
response.Header().Set(receivedHeader, l)
response.WriteHeader(http.StatusOK)
} else {
log.Printf("[HTTP][denied]: %s", l)
response.Header().Set(resultHeader, resultDenied)
response.Header().Set(overrideHeader, request.Header.Get(overrideHeader))
response.Header().Set(receivedHeader, l)
response.WriteHeader(http.StatusForbidden)
_, _ = response.Write([]byte(denyBody))
}
}
La fonction ServeHTTP lit l'en-tête de requête spécifié par la variable checkHeader. Si la valeur de l'en-tête est égale à celle de allowedValue, la fonction renvoie 200 et la requête est autorisée. Dans tous les autres cas, la fonction renvoie 403 et la requête est refusée.
Le code précédent est un extrait de l'implémentation exemple. Le type ExtAuthzServer, la fonction returnIfNotTooLong et les identifiants tels que checkHeader, allowedValue, resultHeader, overrideHeader et receivedHeader sont définis ailleurs dans l'exemple.
Ce service d'autorisation utilise l'en-tête correspondant à la variable checkHeader. Par conséquent, vous devez configurer l'option Carry origin header within auth request lors de l'importation du service d'autorisation personnalisé dans le maillage. Sinon, vous n'obtiendrez pas le résultat attendu.
Intégrer le service d'autorisation personnalisé au maillage
Déployez le service d'autorisation personnalisé développé dans votre cluster Container Service for Kubernetes (ACK), puis associez-le à votre instance ASM dans la console ASM. Cette rubrique couvre uniquement le développement. Pour la procédure complète d'importation du service d'autorisation personnalisé dans le maillage, consultez Implémenter une autorisation personnalisée à l'aide du protocole HTTP.
Après avoir associé le service, spécifiez les proxies de maillage utilisant le service d'autorisation dans une politique d'autorisation. Pour la configuration de la politique d'autorisation, consultez Implémenter une autorisation personnalisée à l'aide du protocole HTTP.