NGINX Ingress is a popular Kubernetes ingress controller for routing traffic into your cluster. A standard Ingress resource lets you map HTTP requests to your Kubernetes services. Here’s how to protect your routes with HTTP Basic Authentication.
Creating an HTPasswd file
Make sure you’ve got an
htpasswd file available before you tackle the Kubernetes configuration. You can create a new single user
htpasswd in your terminal:
apt install apache2-utils htpasswd -c auth example-user
You’ll be prompted to enter the password. A new file called
auth will be created in your working directory.
Next you need to base64-encode your credentials string so it can be used as a value in a Kubernetes secret:
cat auth | base64
Copy the base64-encoded string to your clipboard. We’ll use it in the next section to create a Kubernetes secret containing your credentials.
Adding a Kubernetes Secret
NGINX Ingress references
htpasswd files as Kubernetes secrets. The file’s content must be stored in the
auth key of an
Opaque secret. Kubernetes also has a built-in
basic-auth secret type but this isn’t suitable for NGINX Ingress.
Create a new secret manifest and apply it to your cluster with Kubectl:
apiVersion: v1 kind: Secret type: Opaque metadata: name: htpasswd data: auth: <base64-encoded htpasswd file>
Add your base64-encoded
htpasswd file as the value of the
Modifying Your Ingress
NGINX Ingress supports several custom annotations that let you attach extra behavior to your Ingress resources. To use HTTP Basic Authentication you need to set the
auth-type annotation and supply a reference to your secret.
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: htpasswd nginx.ingress.kubernetes.io/auth-realm: "Enter your credentials" spec: rules: - host: example.com http: paths: - path: / backend: serviceName: example-service servicePort: 80
The three annotations configure NGINX to require authentication on every request that’s matched by your Ingress resource. The
basic authentication type is used with the credentials from the
htpasswd secret created earlier. The
auth-realm annotation defines the message displayed to users when they’re prompted to enter their credentials.
Requests matched by this Ingress will now require the user to login before they continue. The authentication challenge displays as a popup dialog in most web browsers. Enter the username and password supplied to the
htpasswd command to authenticate yourself.
Alternative Secret Form
The secret shown above uses the
auth-file format. This means it’s got an
auth field containing base64-encoded output from the
NGINX Ingress also supports another form termed
auth-map. In this variation, the
auth field is replaced by a set of keys that each provide the password for an individual user.
apiVersion: v1 kind: Secret type: Opaque metadata: name: htpasswd data: user1: <base64-encoded password hash from htpasswd> user2: <base64-encoded password hash from htpasswd>
Add your usernames to the file, then use
htpasswd to generate hashed credentials. Inspect the
htpasswd output; it will have the following format:
Take the password part, encode it with the
base64 command, then add the result to your Kubernetes secret.
NGINX will accept logins from any valid username and password combination defined in the secret. This approach can make it easier to set up multiple user accounts and helps you see exactly who’s got access.
More Advanced Auth
NGINX Ingress can integrate with external authentication providers if you need more control but want a similarly straightforward set up experience. Using an external auth provider will redirect users to that site before they can access the Service behind your Ingress. This lets you enforce a full authentication routine without touching your backend code.
nginx.ingress.kubernetes.io/auth-url annotation defines the URL of an external authentication service to use. Kubernetes will forward each incoming request to the service. Access will only be granted to the user when the service returns a
200 OK status code. The normal flow then continues with the request proceeding into your Kubernetes Service.
When the auth service indicates an error, users will be redirected to the page indicated by the
nginx.ingress.kubernetes.io/auth-signin URL. This will receive the original URL to redirect back to after a successful authentication attempt as a URL parameter defined with the
Several other annotations let you tweak NGINX’s behavior when communicating with the authentication platform. You can change the HTTP method used to make authentication requests, add additional headers, and setup caching for auth responses. The latter ensures you’re not continually hitting the external platform if a user makes several requests to your service in a short period of time.
HTTP Basic Authentication is the simplest way of protecting a website. It’s ideal for internal systems and staging sites where you’re working with a small list of users and don’t need centralized credential management.
Use Basic Auth with NGINX Ingress by supplying credentials in a Kubernetes secret and setting annotations on your Ingress resources. In a real-world use case, you shouldn’t hardcode credentials into your Kubernetes manifests. Either use Helm or a CI/CD system to safely supply values at the time you apply the resources to your cluster.
- › What’s New in Windows 11’s 22H2 Update: Top 10 New Features
- › How Much Does It Cost to Operate an Electric Lawn Mower?
- › NZXT Signal 4K30 Capture Card Review: Lossless High-Quality Footage
- › A World Without Wires: 25 Years of Wi-Fi
- › T-Mobile Is Selling Your App Activity: Here’s How to Opt Out
- › What Are the Best Nintendo Switch Games in 2022?