External auth server setup
Set up the default or customize your own external auth server.This feature is available with a Gloo Mesh Gateway license only.
To enforce external authentication policies, your service mesh environment must have an external auth server. Choose from the following options.
Set up the Gloo Mesh external auth server
To enforce external auth policies across your service mesh environment, each Gloo Mesh workspace must have one and only one external auth server. You can configure an ExtAuthServer
resource to customize the server behavior, or use the default settings.
-
Register your workload clusters with the
ext-auth-service
enabled. Gloo Mesh automatically creates a deployment and service of an external auth server. The example steps set up a separategloo-mesh-addons
namespace to run the external auth server. Use this namespace to refer to your server in theExtAuthServer
resource. -
Create an
ExtAuthServer
resource for your workspace. This resource points to the destination server to use for external auth policies. The destination server can be the defaultext-auth-service
from Gloo Mesh, or your own custom server.Review the following table to understand this configuration.kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: admin.gloo.solo.io/v2 kind: ExtAuthServer metadata: name: default-server namespace: bookinfo spec: destinationServer: port: number: 8083 ref: cluster: cluster-1 name: ext-auth-service namespace: gloo-mesh EOF
You can also use the
ExtAuthServer
resource to customize certain behaviors such as request timeouts, buffering, and HTTP status codes. For more information, see the API reference.Setting Description metadata
The name and namespace for this external auth server resource. You can have only one external auth server resource per workspace. This resource does not have to be in the same namespace as the destination server. However, if this resource and the destination server are not in the same workspace, this resource's workspace must import the destination server's service. destinationServer
The external auth server for Gloo Mesh to use to authentic requests with an external auth policy. If unset, Gloo Mesh looks for a service with the name extauth
in the same namespace as the Gloo Mesh agent on each cluster where the selected workload is deployed. This destination server does not have to be in the same workspace as the external auth server configuration or external auth policies. However, you must export the destination server's service to those workspaces. -
In your external auth policies, refer to the
ExtAuthServer
to use. In the highlighted example, the server configuration is referred to only by name because the policy is created in the same namespace.kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: security.policy.gloo.solo.io/v2 kind: ExtAuthPolicy metadata: name: basic-auth namespace: bookinfo spec: applyToRoutes: - route: labels: route: ratings config: glooAuth: configs: - basicAuth: apr: users: user: hashedPassword: 8BvzLUO9IfGPGGsPnAgSu1 salt: TYiryv0/ server: name: default-server EOF
Bring your own external auth server
Gloo Mesh Gateway comes with an external auth server that implements a wide array of authentication and authorization models. However, you can deploy your own external auth server. Then, configure Gloo Mesh Gateway to use this custom server to secure routes with external auth policies.
For example, you might create a custom external auth server to implement custom logic or to accept requests on certain routes.
The following steps demonstrate how to create a simple HTTP external auth server. Use these steps as a model to deploy your own gRPC server that implements the Envoy spec for an external authorization server.
Before you begin
-
Complete the demo setup to install Gloo Mesh, Istio, and Bookinfo in your cluster.
-
Send a request to verify that you can reach the
ratings
app without authorization. By default, Gloo Mesh allows any request on routes that do not specify authentication. Note that you are sending the request along/ratings/2
.curl -vik --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/ratings/2
Example output:
{"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
Create a simple HTTP external auth server
When a request matches a route that has an external auth policy applied, Gloo Mesh forwards the request to an external auth service.
If that external auth service returns a 200 OK
response, Gloo Mesh considers the request to be authorized and sends it to its original destination. If not, Gloo Mesh denies the request.
You can fine tune settings such as sending headers or forwarding the body by configuring the ExtAuthServer
resource as shown in the previous section. Or, you can create your own external auth server to handle requests.
-
Implement your external auth server. For example, you might use the following Python app for a simple HTTP server. In this example, only requests to
/ratings/1
are authorized. All other requests are denied with a401
response.import http.server import socketserver class Server(http.server.SimpleHTTPRequestHandler): def do_GET(self): path = self.path print("path", path) if path.startswith("/ratings/1"): self.send_response(200, 'OK') else: self.send_response(401, 'Not authorized') self.send_header('x-server', 'pythonauth') self.end_headers() def serve_forever(port): socketserver.TCPServer(('', port), Server).serve_forever() if __name__ == "__main__": serve_forever(8000)
-
Deploy your external auth server to your cluster. Depending on your setup, repeat this step for each workspace where you want to use the external auth server.
-
Verify that the namespace has Istio autoinjection enabled.
kubectl get ns -L istio-injection --context ${REMOTE_CONTEXT1}
If not, enable auto-injection for the namespace such as with the following command, or manually inject the Istio sidecar after you complete the next step. For more information, see the Istio docs.
kubectl label namespace istio-injection=enabled --overwrite <namespace>
-
Create the a deployment for your HTTP server app. The following example uses the
docker.io/kdorosh/sample-auth:0.0.1
sample image, which is based on the HTTP server Python code in the previous step. The deployment is created in thebookinfo
namespace.kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: sample-auth namespace: bookinfo labels: app: sample-auth spec: replicas: 1 selector: matchLabels: app: sample-auth template: metadata: labels: app: sample-auth spec: containers: - name: sample-auth image: docker.io/kdorosh/sample-auth:0.0.1 imagePullPolicy: IfNotPresent ports: - containerPort: 8000 EOF
-
Create a service for your external auth server deployment.
kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF kind: Service apiVersion: v1 metadata: name: auth-service namespace: bookinfo labels: app: sample-auth spec: selector: app: sample-auth # Selects the external auth deployment ports: - protocol: TCP port: 80 # For HTTP traffic targetPort: 8000 # Matches the container port of the external auth deployment name: http # Include this name so that Gloo Mesh knows that this is the HTTP port to use EOF
-
Verify that the external auth server is running.
kubectl get all -l app=sample-auth -n bookinfo --context ${REMOTE_CONTEXT1}
-
Configure Gloo Mesh to use your custom external auth server
Now that you have an external auth server running in your cluster, configure Gloo Mesh to use the server for authentication requests. You use an ExtAuthServer
custom resource.
-
Create an
ExtAuthServer
resource to configure the server.Review the following table to understand this configuration.kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: admin.gloo.solo.io/v2 kind: ExtAuthServer metadata: name: custom-server namespace: bookinfo labels: app: sample-auth spec: destinationServer: port: number: 8000 ref: name: auth-service namespace: bookinfo EOF
You can also use the
ExtAuthServer
resource to customize certain behaviors such as request timeouts, buffering, and HTTP status codes. For more information, see the API reference.Setting Description metadata
The name and namespace for this external auth server resource. You can have only one external auth server resource per workspace. This resource does not have to be in the same namespace as the destination server. However, if this resource and the destination server are not in the same workspace, this resource's workspace must import the destination server's service. destinationServer
The external auth server for Gloo Mesh to use to authentic requests with an external auth policy. If unset, Gloo Mesh looks for a service with the name extauth
in the same namespace as the Gloo Mesh agent on each cluster where the selected workload is deployed. This destination server does not have to be in the same workspace as the external auth server configuration or external auth policies. However, you must export the destination server's service to those workspaces. -
Create an external auth policy that uses your custom auth server.
kubectl apply --context ${REMOTE_CONTEXT1} -f - <<EOF apiVersion: security.policy.gloo.solo.io/v2 kind: ExtAuthPolicy metadata: name: custom-auth namespace: bookinfo labels: app: sample-auth spec: applyToRoutes: - route: labels: route: ratings config: customAuth: {} server: name: custom-server EOF
Review the following table to understand this configuration. For more information, see the API reference.
Setting Description applyToRoutes
Configure which routes to apply the policy to, by using labels. The label matches the app and the route from the route table. If omitted, the policy applies to all routes in the workspace. customAuth
Set this field to use your own custom auth server. server
The external auth server to use for the policy. -
Send a request to the
ratings
app along the/ratings/2
path. Now, your request is denied because the external auth server allows requests only along the/ratings/1
path.curl -vik --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/ratings/2
-
Repeat the previous request along the
/ratings/1
path.curl -vik --resolve www.example.com:80:${INGRESS_GW_IP} http://www.example.com:80/ratings/1
The request succeeds:
{"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
-
Optional: Clean up the resources that you created with the following command.
kubectl delete deploy,svc,extauthserver,extauthpolicy -n bookinfo -l app=sample-auth --context ${REMOTE_CONTEXT1}