Service Mesh (ASM) le permite integrar un servicio de autorización personalizado en el flujo de trabajo de autorización de una malla mediante el protocolo HTTP o gRPC. Este tema describe cómo desarrollar un servicio de autorización personalizado basado en HTTP al que llama el proxy de la malla para decidir si se permite una solicitud.
Información de contexto
Service Mesh (ASM) autentica la identidad de una solicitud antes de que las reglas de autorización se apliquen a la solicitud:
Solicitudes que llegan a una puerta de enlace: configure la autenticación JWT (RequestAuthentication) en la puerta de enlace para autenticar la identidad de las solicitudes.
Solicitudes dentro de la malla: los certificados mTLS que emite la malla autentican de forma predeterminada las identidades de las solicitudes.
Después de confirmar la identidad de una solicitud, puede utilizar una directiva de autorización (AuthorizationPolicy) para restringir el comportamiento de la solicitud. Además de estas funciones estándar, ASM admite la integración con un servicio de autorización personalizado que decide si se permite una solicitud.
Cómo funciona
Cuando integra un servicio de autorización personalizado basado en HTTP, el proxy de la malla (puerta de enlace o sidecar) llena una solicitud de autorización HTTP con la información de la solicitud recibida. Después, el proxy envía la solicitud de autorización al servicio de autorización personalizado, el cual decide si se permite la solicitud.
El código de estado que devuelve el servicio de autorización personalizado determina el resultado:
Un código de estado 200 indica que la solicitud pasa la comprobación y se permite.
Un código de estado 5xx indica que el servicio de autorización personalizado presenta anomalías. En este caso, la solicitud se permite o se deniega según su configuración.
Cualquier otro código de estado indica que la solicitud no pasa la comprobación y se deniega.
Desarrollo del servicio de autorización personalizado basado en HTTP
ASM es compatible con la malla de servicios de código abierto Istio. La comunidad de Istio proporciona una implementación de ejemplo de un servicio de autorización personalizado. Este ejemplo implementa servicios de autorización personalizados tanto para el protocolo HTTP como para gRPC. A continuación se muestra el fragmento correspondiente a la lógica HTTP, ubicado en la función 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 función ServeHTTP lee el encabezado de la solicitud que especifica la variable checkHeader. Si el valor del encabezado coincide con el valor de allowedValue, la función devuelve 200 y se permite la solicitud. En todos los demás casos, la función devuelve 403 y se deniega la solicitud.
El código anterior es un fragmento de la implementación de ejemplo. El tipo ExtAuthzServer, la función returnIfNotTooLong e identificadores como checkHeader, allowedValue, resultHeader, overrideHeader y receivedHeader se definen en otras partes del ejemplo.
Este servicio de autorización utiliza el encabezado que corresponde a la variable checkHeader. Por lo tanto, debe configurar el elemento Carry origin header within auth request cuando importe el servicio de autorización personalizado a la malla. De lo contrario, no obtendrá el resultado esperado.
Integración del servicio de autorización personalizado con la malla
Despliegue el servicio de autorización personalizado que desarrolló en su clúster de Container Service for Kubernetes (ACK) y asocie el servicio con su instancia de ASM en la consola de ASM. Este tema abarca únicamente el desarrollo. Para conocer los pasos completos para importar el servicio de autorización personalizado a la malla, consulte Implement custom authorization by using the HTTP protocol.
Después de asociar el servicio, especifique los proxies de la malla que utilizan el servicio de autorización en una directiva de autorización. Para consultar la configuración de la directiva de autorización, consulte Implement custom authorization by using the HTTP protocol.