Как добавить базовую HTTP-аутентификацию в Kubernetes NGINX Ingress
NGINX Ingress — популярный входной контроллер Kubernetes для маршрутизации трафика в ваш кластер. Стандартный ресурс Ingress позволяет сопоставлять HTTP-запросы с вашими сервисами Kubernetes. Вот как защитить свои маршруты с помощью базовой HTTP-аутентификации.
Создание файла HTTPasswd
Прежде чем приступать к настройке Kubernetes, убедитесь, что у вас есть файл htpasswd. Вы можете создать нового пользователя htpasswd в своем терминале:
apt install apache2-utils htpasswd -c auth example-user
Вам будет предложено ввести пароль. В вашем рабочем каталоге будет создан новый файл с именем auth.
Затем вам нужно закодировать строку учетных данных в base64, чтобы ее можно было использовать в качестве значения в секрете Kubernetes:
cat auth | base64
Скопируйте строку в кодировке base64 в буфер обмена. Мы будем использовать его в следующем разделе для создания секрета Kubernetes, содержащего ваши учетные данные.
Добавление секрета Kubernetes
NGINX Ingress ссылается на файлы htpasswd как на секреты Kubernetes. Содержимое файла должно храниться в ключе auth секрета Opaque. В Kubernetes также есть встроенный секретный тип basic-auth, но он не подходит для NGINX Ingress.
Создайте новый секретный манифест и примените его к своему кластеру с помощью Kubectl:
apiVersion: v1 kind: Secret type: Opaque metadata: name: htpasswd data: auth: <base64-encoded htpasswd file>
Добавьте файл htpasswd в кодировке base64 в качестве значения ключа auth.
Изменение входа
NGINX Ingress поддерживает несколько пользовательских аннотаций, которые позволяют вам придавать дополнительное поведение вашим ресурсам Ingress. Чтобы использовать базовую аутентификацию HTTP, вам необходимо установить аннотацию auth-type и предоставить ссылку на ваш секрет.
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Три аннотации настраивают NGINX на требование аутентификации при каждом запросе, соответствующем вашему ресурсу Ingress. Тип аутентификации basic используется с учетными данными из секрета htpasswd, созданного ранее. Аннотация auth-realm определяет сообщение, отображаемое пользователям, когда им предлагается ввести свои учетные данные.
Запросы, соответствующие этому Ingress, теперь потребуют от пользователя входа в систему, прежде чем они продолжат работу. Запрос проверки подлинности отображается в виде всплывающего диалогового окна в большинстве веб-браузеров. Введите имя пользователя и пароль, предоставленные команде htpasswd, чтобы аутентифицировать себя.
Альтернативная секретная форма
Показанный выше секрет использует формат auth-file. Это означает, что у него есть поле auth, содержащее вывод в кодировке base64 из команды htpasswd.
NGINX Ingress также поддерживает другую форму, называемую auth-map. В этом варианте поле auth заменено набором ключей, каждый из которых предоставляет пароль для отдельного пользователя.
apiVersion: v1 kind: Secret type: Opaque metadata: name: htpasswd data: user1: <base64-encoded password hash from htpasswd> user2: <base64-encoded password hash from htpasswd>
Добавьте свои имена пользователей в файл, а затем используйте htpasswd для создания хешированных учетных данных. Проверьте вывод htpasswd; он будет иметь следующий формат:
username:<hashed password>Возьмите часть пароля, закодируйте ее с помощью команды base64, а затем добавьте результат в свой секрет Kubernetes.
NGINX будет принимать входы в систему с любой действительной комбинацией имени пользователя и пароля, определенной в секрете. Такой подход может упростить настройку нескольких учетных записей пользователей и поможет вам точно увидеть, у кого есть доступ.
Более продвинутая аутентификация
NGINX Ingress может интегрироваться с внешними провайдерами аутентификации, если вам нужен больший контроль, но вы хотите такую же простую настройку. Использование внешнего поставщика аутентификации перенаправит пользователей на этот сайт, прежде чем они смогут получить доступ к Сервису за вашим Ingress. Это позволяет вам применять полную процедуру аутентификации, не затрагивая ваш внутренний код.
Аннотация nginx.ingress.kubernetes.io/auth-url определяет URL-адрес внешней службы аутентификации для использования. Kubernetes будет пересылать каждый входящий запрос в сервис. Доступ будет предоставлен пользователю только тогда, когда служба вернет код состояния 200 OK. Затем обычный поток продолжается, и запрос поступает в вашу службу Kubernetes.
Когда служба аутентификации указывает на ошибку, пользователи будут перенаправлены на страницу, указанную URL-адресом nginx.ingress.kubernetes.io/auth-signin. Он получит исходный URL-адрес для перенаправления назад после успешной попытки аутентификации в качестве параметра URL-адреса, определенного с помощью аннотации auth-signin-redirect-param.
Несколько других аннотаций позволяют настроить поведение NGINX при взаимодействии с платформой аутентификации. Вы можете изменить метод HTTP, используемый для выполнения запросов аутентификации, добавить дополнительные заголовки и настроить кэширование ответов аутентификации. Последнее гарантирует, что вы не будете постоянно обращаться к внешней платформе, если пользователь сделает несколько запросов к вашему сервису за короткий промежуток времени.
Краткое содержание
Базовая HTTP-аутентификация — это самый простой способ защиты веб-сайта. Он идеально подходит для внутренних систем и промежуточных сайтов, где вы работаете с небольшим списком пользователей и не нуждаетесь в централизованном управлении учетными данными.
Используйте обычную аутентификацию с NGINX Ingress, указав учетные данные в секрете Kubernetes и установив аннотации для ваших ресурсов Ingress. В реальном случае использования вы не должны жестко кодировать учетные данные в своих манифестах Kubernetes. Либо используйте Helm, либо систему CI/CD для безопасного предоставления значений во время применения ресурсов к кластеру.