Other proxies with Kubernetes

Contributors: @kdwils, @pushpinderbal

Note

This guide only contains additional proxy setups for using Tinyauth as a forward-auth middleware. For deployment instructions see the Kubernetes guide.

Using with ingress-nginx

Caution

ingress-nginx is deprecated. Consider migrating to a supported ingress component.

This ingress resource configures ingress-nginx to forward authentication checks for the host my-host.domain.com to a specific URL (auth-url). If the user is not authenticated, they will be redirected to a login page (auth-signin).

Documentation for these annotations can be found in the ingress-nginx repository annotations.md.

• nginx.ingress.kubernetes.io/auth-url specifies the URL where ingress-nginx should send requests to verify if the user is authenticated.
• nginx.ingress.kubernetes.io/auth-signin specifies the URL where ingress-nginx should send unauthenticated users to sign in.
• nginx.ingress.kubernetes.io/auth-signin-redirect-param specifies the key of the query parameter used to set the redirect URI.

Note

This example uses the <my-service>.<my-namespace>.svc.cluster.local in-cluster URI based on the above example for the auth-url. The auth-signin annotation should be a reference to a URI that is accessible to the user.

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-namespace
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "http://tinyauth.tinyauth.svc.cluster.local:3000/api/auth/nginx"
    nginx.ingress.kubernetes.io/auth-signin: "http://auth.example.com/login"
    nginx.ingress.kubernetes.io/auth-signin-redirect-param: redirect_uri
spec:
  ingressClassName: nginx
  rules:
    - host: my-host.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 8080

Using with Istio

External authorization in Istio is configured using the AuthorizationPolicy CRD and can be set up to use Tinyauth as the external authorization provider for both Ingress and Gateway API resources. Istio uses Envoy proxy under the hood, so this configuration can also be adapted for standalone Envoy filters.

Define the External Authorizer

Add Tinyauth as an external authorization provider in your Istio mesh configuration.

Note

This example uses the <my-service>.<my-namespace>.svc.cluster.local in-cluster URI with the assumption that Istio and Tinyauth exist in the same Kubernetes cluster and the Tinyauth service is accessible from the Istio ingress pods. The URL accessible to end users (e.g., http://auth.example.com) is configured with TINYAUTH_APPURL.

extensionProviders:
- name: "tinyauth"
  envoyExtAuthzHttp:
    service: "tinyauth.tinyauth.svc.cluster.local"
    port: "3000"
    pathPrefix: "/api/auth/envoy?path="
    includeRequestHeadersInCheck: ["cookie", "x-forwarded-for", "x-forwarded-proto", "x-forwarded-host", "accept", "user-agent"]
    includeAdditionalHeadersInCheck:
      "x-forwarded-for": "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
      "x-real-ip": "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
      "x-forwarded-proto": "%REQ(:SCHEME)%"
      "x-forwarded-host": "%REQ(:AUTHORITY)%"
      "x-forwarded-uri": "%REQ(:PATH)%"
      "x-forwarded-method": "%REQ(:METHOD)%"
    headersToDownstreamOnAllow: ["set-cookie"]
    headersToDownstreamOnDeny: ["content-type", "set-cookie"]

Note

• Envoy forwards requests to the external authorizer with the original path from the client request. The pathPrefix configuration above prefixes the path with an endpoint that Tinyauth recognizes, while Tinyauth ignores the original request path.
• Unlike other proxy implementations, Envoy connects to the external authorization backend using the original HTTP method from the client request and cannot be configured to use a static method. Tinyauth handles this by allowing all standard HTTP methods on the /api/auth/envoy endpoint. See envoyproxy/envoy#5357 for more information related to this behavior.

If you install Istio using helm, you can supply extensionProviders configuration in the values.yaml files as follows:

meshConfig:
  extensionProviders:
  - name: "tinyauth"
    envoyExtAuthzHttp:
      service: "tinyauth.tinyauth.svc.cluster.local"
      port: "3000"
      pathPrefix: "/api/auth/envoy?path="
      includeRequestHeadersInCheck: ["cookie", "x-forwarded-for", "x-forwarded-proto", "x-forwarded-host", "accept", "user-agent"]
      includeAdditionalHeadersInCheck:
        "x-forwarded-for": "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
        "x-real-ip": "%DOWNSTREAM_REMOTE_ADDRESS_WITHOUT_PORT%"
        "x-forwarded-proto": "%REQ(:SCHEME)%"
        "x-forwarded-host": "%REQ(:AUTHORITY)%"
        "x-forwarded-uri": "%REQ(:PATH)%"
        "x-forwarded-method": "%REQ(:METHOD)%"
      headersToDownstreamOnAllow: ["set-cookie"]
      headersToDownstreamOnDeny: ["content-type", "set-cookie"]

Create Authorization Policy

Given that you have a HTTPRoute under a Gateway that exposes your application, you can now create an AuthorizationPolicy to protect it using Tinyauth.

http-route.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: myapp-http-route
  labels:
    app: myapp
spec:
  parentRefs:
    - name: my-public-gateway
      namespace: ingress
      sectionName: https
  hostnames:
    - myapp.example.com
  rules:
    - backendRefs:
        - name: myapp-service
          port: 80

authorization-policy.yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: tinyauth-policy
  namespace: ingress
spec:
  targetRefs:
    - kind: Gateway
      group: gateway.networking.k8s.io
      name: my-public-gateway
  action: CUSTOM
  provider:
    name: "tinyauth"
  rules:
  - to:
    - operation:
        hosts: ["myapp.example.com"]

For more information, refer to the Istio External Authorization and Authorization Policy documentation.