Configure Additional Security Measures for a Service

When a service is exposed using a Gateway resource, the App Owner can configure a range of measures to secure their services. The Gateway resource (TSB / TSE) supports the following capabilities:

• HTTP support across clusters or service instances, with TLS, routing, load-balancing and redirects
• TCP support across clusters or service instances, with TLS, routing and load balancing
• Authentication using JWT tokens
• Authorization against external authorization service
• Rate-limiting on a per-second, minute or hour basis, based on client address, and HTTP headers, path and method
• WASM plugins to implement custom traffic management capabilities

Security Capabilities

From a security perspective, the two useful capabilities are:

1. Authentication and Authorization

   Rather than building authentication methods into the destination services, the Ingress Gateway can inspect and authorize traffic based on the content of JWT tokens. This simplifies the service configuration, centralizes authentication, ensures consistency with other services and allows for different security postures (for example, dev, test and production) without any application changes.

2. Rate Limiting

   By limiting requests per-second/minute/hour at the Ingress Gateway, an upstream service can be protected from the impact of spikes of traffic. Individual 'greedy' consumers of resources (such as scraping bots and spiders) can be limited, and brute-force attempts to take over accounts can be rendered impossible.

Apps: Configure Authentication and Authorization

The Tetrate platform provides authorization capabilities to authorize each HTTP request received by an Ingress Gateway. It supports local authorization by using JWT claims, and external authorization (ext-authz) against an external service to determine if a request should be allowed or denied.

You may decide to use an external authorization system if you have a separate in-house system, if you want to use another authentication schema than JWT or if you want to integrate with a third party authorization solution such as Open Policy Agent (OPA) or PlainID:

Example Authentication and Authorization using authz

apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
  name: ingress-bookinfo
  group: g1
  workspace: w1
  tenant: tse
  organization: tse
spec:
  workloadSelector:
    namespace: ns1
    labels:
      app: gateway
  http:
  - name: bookinfo
    port: 9443
    hostname: bookinfo.com
    tls:
      mode: SIMPLE
      secretName: bookinfo-certs
    authentication:
      rules:
        jwt:
        - issuer: https://accounts.google.com
          jwksUri: https://www.googleapis.com/oauth2/v3/certs
        - issuer: "auth.mycompany.com"
          jwksUri: https://auth.mycompany.com/oauth2/jwks
    authorization:
      external:
        uri: https://company.com/authz
        includeRequestHeaders:
          - Authorization # forwards the header to the authorization service.
    routing:
      rules:
      - route:
          serviceDestination:
            host: ns1/productpage.ns1.svc.cluster.local

For detailed information, check out the Tetrate Service Bridge how-tos, which also apply to TSE.

Apps: Configure Rate Limiting

Rate limiting allows you to restrict the traffic through your Ingress Gateway to a predetermined limit. You can categorize traffic attributes such as source IP address and HTTP Headers, rate-limiting each category individually.

Example Rate Limiting

apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
  name: ingress-bookinfo
  group: g1
  workspace: w1
  tenant: tse
  organization: tse
spec:
  workloadSelector:
    namespace: ns1
    labels:
      app: gateway
  http:
  - name: bookinfo
    port: 9443
    hostname: bookinfo.com
    tls:
      mode: SIMPLE
      secretName: bookinfo-certs
    routing:
      rules:
      - route:
          serviceDestination:
            host: ns1/productpage.ns1.svc.cluster.local
    rateLimiting:
      settings:
        rules:
          # Ratelimit at 10 requests/hour for clients with a remote address of 1.2.3.4
        - dimensions:
          - remoteAddress:
              value: 1.2.3.4
          limit:
            requestsPerUnit: 10
            unit: HOUR
          # Ratelimit at 50 requests/minute for every unique value in the user-agent header
        - dimensions:
          - header:
              name: user-agent
          limit:
            requestsPerUnit: 50
            unit: MINUTE
          # Ratelimit at 100 requests/second for every unique client remote address
          # with the HTTP requests having a GET method and the path prefix of /productpage
        - dimensions:
          - remoteAddress:
              value: "*"
          - header:
              name: ":path"
              value:
                prefix: /productpage
          - header:
              name: ":method"
              value:
                exact: "GET"
          limit:
            requestsPerUnit: 100
            unit: SECOND

You may want to consider rate limiting if you are concerned with any of the following:

• To prevent malicious volume-based activity such as DDoS attacks or brute-force attacks
• To limit the impact of poorly-behaved spiders, bots or scrapers
• To prevent your applications and its resources (such as a database) from being overloaded
• To implement fair business logic such as applying different API limits for different sets of users.

For detailed information, check out the Tetrate Service Bridge how-to, which also applies to TSE.