Technical

Implementing a Custom Integration in the Gateway: An Example With AWS SigV4

In today’s digital world, businesses need to connect and manage external services securely and efficiently. One useful tool for this is Gloo Gateway from Solo.io, an API gateway that helps businesses integrate with external APIs easily.

When we talk about custom integration, we mean setting up these connections to work smoothly and securely with your business’s systems. A clear example of this in action is using AWS Signature Version 4 (Sigv4). Sigv4 is a method for securely adding authentication information to requests made to AWS services.

This guide will show you how the Gloo Gateway can handle Sigv4, making sure that your interactions with AWS services like S3 are secure and well-managed, which is essential for protecting your data and ensuring reliable service.

Why would I want to sign the request in the gateway?

Integrating AWS Signature Version 4 for accessing an S3 bucket directly through a gateway like Gloo Gateway offers several advantages, especially in terms of security, scalability, and architectural simplicity. Here’s a detailed breakdown of why it is beneficial:

  • Enhanced security: Time-limited signatures (usually 15m), message integrity with hashed payloads, and scoped credentials managed by the gateway
  • Centralized management: Reduced complexity and security risks as credentials are managed and rotated in a single location, and consistency as the gateway can enforce security policies across all requests
  • Scalability and performance: Services behind the gateway don’t need to handle AWS-specific authentication, and the gateway can potentially cache signed requests speeding up the overall interactions
  • Architectural cleanliness: Same policies across services regarding external systems like AWS
  • Regulatory compliance: Access logs, monitoring, security practices, and everything else that is provided out of the box by an enterprise gateway

External Service Definition

First, we are going to define the external destination for the traffic.

apiVersion: networking.gloo.solo.io/v2
kind: ExternalService
metadata:
  name: s3-secured-bucket
  namespace: httpbin
  labels:
    expose: "true"
spec:
  hosts:
  - my-secured-bucket.s3.us-east-2.amazonaws.com
  ports:
  - name: https
  number: 443
  protocol: HTTPS
  clientsideTls: {}

Route Table Configuration

This part specifies how the requests should be routed within the Gloo Gateway. It has two routes: one for handling typical HTTP requests to internal services (/get and /headers paths) and another route (/cake.json), which is forwarded to the defined external service (S3 bucket).

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: httpbin
  namespace: httpbin
  labels:
    expose: "true"
spec:
  http:
  - name: httpbin
    labels:
    apikeys: "false"
    matchers:
    - uri:
        exact: /get
    - uri:
        exact: /headers
    forwardTo:
      destinations:
      - ref:
          name: in-mesh
          namespace: httpbin
          cluster: cluster1
        port:
          number: 8000
  - name: aws
    labels:
      apikeys: "true"
    matchers:
    - uri:
        exact: /cake.json
    forwardTo:
      autoHostRewrite: true
      destinations:
      - kind: EXTERNAL_SERVICE
        port:
          number: 443
        ref:
          name: s3-secured-bucket
          namespace: httpbin

External Authentication Policy

This policy configures authentication for routes that require external validation. It utilizes an external authentication server to validate requests and ensures that specific headers related to AWS authentication are appropriately handled.
It is composed of two steps, the authorization with an API key and then the signing of the request to be sent to AWS.

apiVersion: security.policy.gloo.solo.io/v2
kind: ExtAuthPolicy
metadata:
  name: httpservice
  namespace: httpbin
spec:
  applyToRoutes:
  - route:
      labels:
        apikeys: "true"
  config:
    server:
      name: ext-auth-server
      namespace: gloo-mesh-addons
      cluster: cluster1
    glooAuth:
      configs:
      - apiKeyAuth:
          headerName: api-key
          k8sSecretApikeyStorage:
            labelSelector:
              auth: api-key
      - passThroughAuth:
          http:
            url: http://extauth-httpservice.gloo-mesh-addons.svc.cluster.local:9001
            connectionTimeout: 5s
            response:
              allowedUpstreamHeadersToOverwrite:
              - authorization
              allowedUpstreamHeaders:
              - x-amz-date
              - x-amz-content-sha256

The apikeys can be easily created as Kubernetes secrets, and stored in a storage backend as redis as well:

apiVersion: v1
kind: Secret
metadata:
  name: user1
  namespace: httpbin
  labels:
    auth: api-key
type: extauth.solo.io/apikey
stringData:
  api-key: apikey1
  user-id: user1
  user-email: user1@solo.io
  usagePlan: gold

Custom Code for the Integration

The custom code is developed in nodejs, and compiled in a oci image:

import express from "express";
import _signer from "@fgiova/aws-signature";

const app = express();
const port = 9001;
const signer = new _signer.Signer();

app.post('/', (req, res) => {
  console.debug(`received request with url ${req.url} and headers ${JSON.stringify(req.headers)}`);
  console.log(`MEthod ${req.method}`);
  console.log(`Headers ${JSON.stringify(req.headers)}`);
  console.log(`Body ${JSON.stringify(req.path)}`);
  signer.request({
    method: "GET",
    path: "/cake.json",
    headers: {
      host: "my-secured-bucket.s3.us-east-2.amazonaws.com",
    },
  }, "s3")
    .then((value) => {
      res.setHeader('x-amz-date', value.headers['x-amz-date']);
      res.setHeader('x-amz-content-sha256', value.headers['x-amz-content-sha256']);
      res.setHeader('Authorization', value.headers['Authorization']);
      console.debug(`signature: ${JSON.stringify(value)}`);
      res.sendStatus(200);
    });
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

Now we are ready to send requests to our gateway endpoint and get responses from aws s3 bucket, just browsing:

curl https://gloo-secured-gateway.solo.io/cake.json -H 'api-key: apikey1'

Gloo Gateway Custom Integrations

AWS sigV4 is just one of the multiple possibilities that can be implemented and used in the gateway.

A custom integration can be easily implemented following these same steps, and developed in the language of your choice for practically any requirement. This could be anything from cloud storage services like AWS S3, to third-party APIs for payment processing, social media integrations, or data analytics platforms.

By abstracting the complexity of external integrations to a gateway layer, you create a centralized, secure, and scalable point of control that can adapt to various external APIs with minimal impact on your core application logic. Whether you’re integrating with one service or many, the gateway approach provides a robust framework for extending your application’s capabilities in a controlled and efficient manner.

Want to expand your API gateway knowledge? Discover more by reading our detailed buyer’s guide on API gateways.

This guide explores key features that make API gateways an essential tool for any modern application architecture. Whether you’re new to API gateways or looking to enhance your existing setups, you’ll gain valuable insights and tips. Dive deeper and enhance your expertise today!

A Buyer's Guide to API Gateways