Configure Additional Security Measures for a Service

Use this section when an application needs authentication, authorization or rate limits at its Ingress Gateway.

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 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 or OIDC
• Authorization using local rules or an external authorization service
• Rate-limiting on a per-second, minute or hour basis, based on client address, and HTTP headers, path and method
• Web Application Firewall (WAF) protection
• WASM plugins and other extensions to implement custom traffic management capabilities

Security Capabilities

From a security perspective, the two useful capabilities are:

• 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.
• 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 slowed down.

RunBook

1. 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
     namespace: ns1
     annotations:
       tsb.tetrate.io/organization: tetrate
       tsb.tetrate.io/tenant: tetrate
       tsb.tetrate.io/workspace: w1
       tsb.tetrate.io/gatewayGroup: g1
   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 JWT authentication and OIDC authentication how-tos, and the external authorization how-tos.

2. 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.

   Ask your Platform Owner to enable rate limiting

   The following example uses global rate limits, which require the Platform Owner to first enable the rate limit server and its Redis backend. If the server is not available, you can use local rate limiting instead, where each Gateway instance applies its own limit.

   Example Rate Limiting

   apiVersion: gateway.tsb.tetrate.io/v2
   kind: Gateway
   metadata:
     name: ingress-bookinfo
     namespace: ns1
     annotations:
       tsb.tetrate.io/organization: tetrate
       tsb.tetrate.io/tenant: tetrate
       tsb.tetrate.io/workspace: w1
       tsb.tetrate.io/gatewayGroup: g1
   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 rate limiting how-tos.