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.

  1. Install Gloo Mesh Enterprise with the external authentication feature enabled.

  2. Install the Istio Bookinfo sample application.

  3. Confirm that your workstation has tools to generate hashed, salted passwords, such as htpasswd, and to encode strings, such as base64.

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.

  1. 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}}
    
  2. Update the traffic policy for the ratings destination so that only requests by the user user with password password 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 and
    • 8BvzLUO9IfGPGGsPnAgSu1 is the hashed password.
  3. Create an AuthConfig custom resource with the salt and hashed password values. Make sure that the labels match your app, such as the bookinfo 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/
       

  4. Update the TrafficPolicy to refer to the AuthConfig.

       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

  1. 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
       
  2. Encode the user user and password password in base64 so that you can test an authenticated request.

    echo -n "user:password" | base64
    

    Example output:

    dXNlcjpwYXNzd29yZA==
    
  3. 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