mirror of
https://github.com/hanzoai/ingress.git
synced 2026-10-26 02:47:15 +00:00
Hanzo CI/CD / cicd (push) Failing after 9m46s
CI/CD / cicd (push) Failing after 10m4s
Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env, `traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations, `.traefik.yml` plugins and `traefik_*` metrics. This binary answers to `INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and `ingress.*` — a reader following the old text configured nothing. Two were worse than stale. Gateway API examples gave `group: traefik.io` for an IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai. The contributing guide built with `github.com/traefik/ingress` ldflags against a module that is `github.com/hanzoai/ingress/v3`. script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD dumps had been deleted and never regenerated, so `cat` failed the script under `set -e`. controller-gen v0.19.0 restores all ten; they concatenate byte-for-byte into the committed definition and fixture. CHANGELOG.md is untouched: 6,789 lines of imported release history, where a rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`, `traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the MIT attribution stay — upstream's addresses, not our brand. Co-authored-by: Hanzo Dev <[email protected]>
3.9 KiB
3.9 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress DigestAuth Documentation | Hanzo Ingress's HTTP DigestAuth middleware restricts access to your services to known users. Read the technical documentation. |
The DigestAuth middleware grants access to services to authorized users only.
Configuration Examples
# Declaring the user list
http:
middlewares:
test-auth:
digestAuth:
users:
- "test:ingress:a2688e031edb4be6a3797f3882655c05"
- "test2:ingress:518845800f9e2bfb1f1f740ec24f074e"
# Declaring the user list
[http.middlewares]
[http.middlewares.test-auth.digestAuth]
users = [
"test:ingress:a2688e031edb4be6a3797f3882655c05",
"test2:ingress:518845800f9e2bfb1f1f740ec24f074e",
]
# Declaring the user list
labels:
- "ingress.http.middlewares.test-auth.digestauth.users=test:ingress:a2688e031edb4be6a3797f3882655c05,test2:ingress:518845800f9e2bfb1f1f740ec24f074e"
// Declaring the user list
{
//...
"Tags" : [
"ingress.http.middlewares.test-auth.digestauth.users=test:ingress:a2688e031edb4be6a3797f3882655c05,test2:ingress:518845800f9e2bfb1f1f740ec24f074e"
]
}
# Declaring the user list
apiVersion: hanzo.ai/v1alpha1
kind: Middleware
metadata:
name: test-auth
spec:
digestAuth:
secret: userssecret
Configuration Options
| Field | Description | Default | Required |
|---|---|---|---|
users |
Array of authorized users. Each user must be declared using the name:realm:encoded-password format.The option users supports Kubernetes secrets.(More information here) |
[] | No |
usersFile |
Path to an external file that contains the authorized users for the middleware. The file content is a list of name:realm:encoded-password. (More information here) |
"" | No |
realm |
Allow customizing the realm for the authentication. | "ingress" | No |
headerField |
Allow defining a header field to store the authenticated user. | "" | No |
removeHeader |
Allow removing the authorization header before forwarding the request to your service. | false | No |
Passwords format
Passwords must be hashed using MD5, SHA1, or BCrypt.
Use htpasswd to generate the passwords.
users & usersFile
- If both
usersandusersFileare provided, they are merged. The contents ofusersFilehave precedence over the values in users. - Because referencing a file path isn’t feasible on Kubernetes, the
users&usersFilefield isn’t used in Kubernetes IngressRoute. Instead, use thesecretfield.
Kubernetes Secrets
On Kubernetes, you don’t use the users or usersFile fields. Instead, you reference a Kubernetes secret using the secret field in your Middleware resource. This secret can be one of two types:
kubernetes.io/basic-auth secret: This secret type contains two keys—usernameandpassword—but is generally suited for a smaller number of users. Please note that these keys are not hashed or encrypted in any way, and therefore is less secure than the other method.- Opaque secret with a users field: Here, the secret contains a single string field (often called
users) where each line represents a user. This approach allows you to store multiple users in one secret.
{% include-markdown "includes/ingress-for-business-applications.md" %}