feat: changes for v5.1.2

astro.config.mjs

@@ -120,6 +120,10 @@ export default defineConfig({
               label: "Tailscale",
               slug: "docs/guides/tailscale",
             },
+            {
+              label: "Kubernetes",
+              slug: "docs/guides/kubernetes",
+            },
             {
               label: "Using the Binary",
               slug: "docs/guides/using-the-binary",

src/content/docs/docs/community/kubernetes.mdx

@@ -1,106 +1,20 @@
 ---
-title: Kubernetes
-description: Learn how to set up Tinyauth with Kubernetes resources.
+title: Other proxies with Kubernetes
+description: Use a Tinyauth deployment as a forward-auth middleware with different proxies.
 ---
 
 _Contributors: [@kdwils](https://github.com/kdwils), [@pushpinderbal](https://github.com/pushpinderbal)_
 
-## Use Case
-
-Kubernetes-hosted applications are commonly exposed externally using [Ingress Controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) or the newer [Gateway API](https://kubernetes.io/docs/concepts/services-networking/gateway/). These can act as a gateway to enforce authentication and authorization policies before traffic reaches your self-hosted applications. This is useful for protecting internal tools, admin interfaces, or services exposed to the internet - without needing to modify the applications themselves, especially those that do not have built-in authentication mechanisms.
-
-Popular reverse proxies like Nginx, Traefik, and Envoy provide Ingress controller and Gateway API implementations for Kubernetes that can be integrated with Tinyauth.
-
-## Prerequisites
-
-This guide assumes the following prerequisites:
-
-- An operational Kubernetes cluster
-- An operational Ingress controller or Gateway API implementation (this guide demonstrates `ingress-nginx` and `Istio`, but `traefik` can be used as well).
-- Experience with Kubernetes
-
-## Create a Namespace
-
-Firstly, create a namespace for Tinyauth:
-
-```yaml
-apiVersion: v1
-kind: Namespace
-metadata:
-  name: tinyauth
-```
-
-## Create a Deployment
-
-Create the Tinyauth deployment:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: tinyauth
-  labels:
-    app: tinyauth
-spec:
-  replicas: 1
-  selector:
-    matchLabels:
-      app: tinyauth
-  template:
-    metadata:
-      labels:
-        app: tinyauth
-    spec:
-      containers:
-        - name: tinyauth
-          image: ghcr.io/tinyauthapp/tinyauth:v5
-          ports:
-            - containerPort: 3000
-          env:
-            - name: TINYAUTH_APPURL
-              value: http://auth.example.com
-            - name: TINYAUTH_AUTH_USERS
-              value: user:$$2a$$10$$UdLYoJ5lgPsC0RKqYH/jMua7zIn0g9kPqWmhYayJYLaZQ/FTmH2/u # Username is user and password is password
-          livenessProbe:
-            exec:
-              command:
-                - tinyauth
-                - healthcheck
-            initialDelaySeconds: 10
-            periodSeconds: 30
-          readinessProbe:
-            exec:
-              command:
-                - tinyauth
-                - healthcheck
-            initialDelaySeconds: 5
-            periodSeconds: 10
-```
-
-It is recommended  (and required for IP address ACLs) that you also set the `TINYAUTH_AUTH_TRUSTEDPROXIES` environment variable to the IP address of your Nginx/Istio instance so Tinyauth can trust the `X-Real-IP` and `X-Forwarded-For`headers and get the correct client IP.
-
-## Create a Service
-
-Create the service:
-
-```yaml
-apiVersion: v1
-kind: Service
-metadata:
-  name: tinyauth
-spec:
-  selector:
-    app: tinyauth
-  ports:
-    - port: 3000
-      targetPort: 3000
-  type: ClusterIP
-```
+:::note
+This guide only contains additional proxy setups for using Tinyauth
+as a forward-auth middleware. For deployment instructions see the
+Kubernetes [guide](/docs/guides/kubernetes).
+:::
 
 ## Using with ingress-nginx
 
 :::caution
-`ingress-nginx` is set to be [retired in March 2026](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/). Consider migrating to a supported ingress component.
+`ingress-nginx` is [deprecated](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement). 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`).
@@ -112,10 +26,11 @@ Documentation for these annotations can be found in the ingress-nginx repository
 - `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.
+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.
 :::
 
-```yaml
+```yaml title="ingress.yaml"
 apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
@@ -142,14 +57,19 @@ spec:
 
 ## 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](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter).
+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](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter).
 
 ### 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`.
+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`.
 :::
 
 ```yaml
@@ -172,8 +92,13 @@ extensionProviders:
 ```
 
 :::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](https://github.com/envoyproxy/envoy/issues/5357) for more information related to this behavior.
+- 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](https://github.com/envoyproxy/envoy/issues/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:
@@ -182,14 +107,28 @@ If you install Istio using helm, you can supply `extensionProviders` configurati
 meshConfig:
   extensionProviders:
   - name: "tinyauth"
-    ....<rest of the config as above>....
+    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.
+Given that you have a `HTTPRoute` under a Gateway that exposes your application, you can now create
+an `AuthorizationPolicy` to protect it using Tinyauth.
 
-```yaml
+```yaml title="http-route.yaml"
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -209,7 +148,7 @@ spec:
           port: 80
 ```
 
-```yaml
+```yaml title="authorization-policy.yaml"
 apiVersion: security.istio.io/v1
 kind: AuthorizationPolicy
 metadata: