East-west external auth
Overview
This section refers to using the Gloo Mesh Enterprise external auth server to authenticate requests for east-west traffic across the services inside the service mesh. For authentication of north-south traffic, see the Gloo Mesh Gateway authentication guides.
Gloo Mesh Enterprise provides a variety of authentication options to meet the needs of your environment, from basic user credentials to complex, fine-grained, and secure access control.
Envoy supports basic authentication options such as JSON web token (JWT) verification, but for many authentication requests at scale, prefers an external service supported through the external auth filter. Architecturally, Gloo Mesh provides a dedicated external authentication server (Ext Auth) to verify the user credentials and validate user permissions. Ext Auth can support several authentication and authorization (authN/Z) implementations, or you can provide your own auth server to implement custom logic.
Auth configuration overview
You can configure authentication in a top-level AuthConfig
custom resource, as shown in the following example.
The resource spec
consists of an array of configs
that are executed in sequence when a request matches the AuthConfig
(more on how requests are matched to AuthConfigs
shortly). If any of these authentication configs fails, the request is denied (this behavior is configurable). In most cases, an AuthConfig
has a single config
.
apiVersion: enterprise.gloo.solo.io/v1
kind: AuthConfig
metadata:
name: basic-auth
namespace: gloo-system
spec:
configs:
- basicAuth:
apr:
users:
user:
hashedPassword: 14o4fMw/Pm2L34SvyyA2r.
salt: 0adzfifo
realm: gloo
Before you begin
External auth for east-west traffic requires at least Gloo Mesh Enterprise version 1.2.
-
Install Gloo Mesh Enterprise with the external authentication feature enabled.
-
Install the Istio Bookinfo sample application.
-
Confirm that your workstation has tools to generate hashed, salted passwords, such as
htpasswd
, and to encode strings, such asbase64
.
Require authentication for the destination
By default, Gloo Mesh Enterprise allows requests to destinations without requiring authentication. You can change the default behavior and use external auth to require credentials across requests in your service mesh.
-
Send a request to the ratings destination.
kubectl exec $(kubectl get pod -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') --namespace=bookinfo -c productpage -- curl -sS reviews:9080/reviews
Notice that in the output, you are able to reach the destination without having to provide any credentials.
{"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
-
Update the traffic policy for the ratings destination so that only requests by the user
user
with passwordpassword
are allowed. Gloo Mesh expects the password to be hashed and salted using the APR1 format. Passwords in this format follow this pattern:$apr1$**SALT**$**HASHED_PASSWORD**
.htpasswd -nbm user password
Example output:
user:$apr1$TYiryv0/$8BvzLUO9IfGPGGsPnAgSu1
, where:TYiryv0/
is the salt and8BvzLUO9IfGPGGsPnAgSu1
is the hashed password.
-
Create an
AuthConfig
custom resource with the salt and hashed password values. Make sure that the labels match your app, such as thebookinfo
sample app.apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: labels: app: bookinfo-policies app.kubernetes.io/name: bookinfo-policies name: basic-auth namespace: bookinfo spec: configs: - basicAuth: apr: users: user: hashedPassword: 8BvzLUO9IfGPGGsPnAgSu1 salt: TYiryv0/
-
Update the
TrafficPolicy
to refer to theAuthConfig
.apiVersion: networking.mesh.gloo.solo.io/v1 kind: TrafficPolicy metadata: labels: app: bookinfo-policies app.kubernetes.io/name: bookinfo-policies name: tp-extauth namespace: bookinfo spec: destinationSelector: - kubeServiceRefs: services: - clusterName: mgmt-cluster name: reviews namespace: bookinfo policy: extauth: configRef: name: basic-auth namespace: bookinfo extauthSettings: {}
Your destination is set up to deny unauthenticated requests! Now for a request to be allowed, the request must include the user credentials inside the expected header in the following format.
Authorization: basic <base64_encoded_credentials>
Continue to the next section to test out the authentication.
Testing authentication for requests
-
Resend the previous request.
kubectl exec $(kubectl get pod -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') --namespace=bookinfo -c productpage -- curl -sS reviews:9080/reviews
Notice that the response now contains a 401 Unauthorized code, indicating that Gloo Mesh denied the request.
> GET /posts/1 HTTP/1.1 > Host: foo > User-Agent: curl/7.54.0 > Accept: */* > < HTTP/1.1 401 Unauthorized < www-authenticate: Basic realm="" < date: Mon, 07 Oct 2019 13:36:58 GMT < server: envoy < content-length: 0
-
Encode the user
user
and passwordpassword
in base64 so that you can test an authenticated request.echo -n "user:password" | base64
Example output:
dXNlcjpwYXNzd29yZA==
-
Include the encoded credentials in the header of your request.
kubectl exec $(kubectl get pod -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') --namespace=bookinfo -c productpage -- curl -sS reviews:9080/reviews -H "Authorization: basic dXNlcjpwYXNzd29yZA=="
You can reach the ratings service again!
{"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
Logging
View the ext-auth-service
deployment logs to verify that the AuthConfig
was set up succesfully.
kubectl logs -n gloo-mesh deploy/ext-auth-service -c ext-auth-service -f
In the example output, notice the got new config
success message.
"logger":"extauth","caller":"runner/run.go:179","msg":"got new config"
Summary
In this tutorial, you installed Gloo Mesh Enterprise with external auth enabled, created a basic authentication AuthConfig
, and configured a TrafficPolicy
to use the AuthConfig
to secure requests to your app.
To clean up the resources that you created, run the following commands.
kubectl delete ac -n bookinfo basic-auth
kubectl delete tp -n bookinfo tp-extauth