С помощью существующего протокола единого входа OpenID Connect 9 страница




 

 
72 v Глава 5. Программируемость и автоматизация                                                       

могут быть написаны на языке Python. Salt предоставляет язык шабло- нов Jinja2 для состояний, а также для файлов. Однако для файлов суще- ствует множество других опций, таких как Mako, сам Python и др. Salt работает в конфигурации «ведущий–ведомый», а также в конфигура- ции «без ведущего». Ведомые устройства носят название миньоны. Од- нако транспорт взаимодействия «ведущий–ведомый» в SaltStack отли- чается от других систем. Работая с Salt, вы можете выбрать протоколы ZeroMQ, TCP или RAET для передачи агенту; или можно не использовать агента, и вместо этого ведущее устройство может применять проколол SSH. Поскольку транспортный уровень по умолчанию асинхронный, SaltStack построен таким образом, чтобы иметь возможность доставить свое сообщение большому числу миньонов с низкой нагрузкой на глав- ный сервер.

См. также:

https://docs.saltstack.com/en/latest/https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.

states.pkg.installedhttps://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.

 
states. fi le.managedhttps://docs.saltstack.com/en/latest/topics/jinja/index.html

 

5.7. Автоматизация конфигураций с помощью Consul

Задача

Вам необходимо автоматизировать конфигурацию NGINX, чтобы ре- агировать на изменения в вашей среде с помощью Consul.

Решение

Используйте демон consul-template и файл шаблона, чтобы создать шаб-

лон файла конфигурации NGINX на ваш выбор:

upstream backend { {{range service "app.backend"}} server {{.Address}};{{end}}

}

 

Этот пример представляет собой файл шаблона Consul, который фор- мирует шаблон конфигурации блока upstream backend. Этот шаблон будет


 

 
                                        5.7. Автоматизация конфигураций с помощью Consul v 73

осуществлять итерацию узлов в Consul, идентифицированном как app. backend. Для каждого узла в Consul шаблон создаст директиву сервера с IP-адресом этого узла.

Демон consul-template запускается из командной строки и может ис- пользоваться для перезагрузки NGINX при каждом изменении установ- ленного шаблона файла настройки:

# consul-template -consul consul.example.internal -template \ template:/etc/nginx/conf.d/upstream.conf:"nginx -s reload"

 

 
Данная команда указывает демону consul-template подключиться к кластеру Consul в consul.example.internal и использовать файл с именем template в текущем рабочем каталоге для выработки файла шаблона и вывода сгенерированного содержимого в /etc/nginx/conf.d./upstream. conf с последующей перезагрузкой NGINX при каждом изменении дан- ного файла шаблона. Флаг -template принимает строку файла template, расположение вывода и команду, запускаемую после того, как происхо- дит процесс создания шаблона; эти три переменные разделены двое- точием. Если в выполняемой команде есть пробелы, убедитесь, что она заключена в двойные кавычки. Флаг -consul сообщает демону, с каким кластером Consul устанавливать соединение.

 

Обсуждение

Consul – это мощный инструмент для обнаружения служб и храни- лище настроек. Он хранит информацию об узлах, а также пары ключ/ значение в структуре, напоминающей каталог, и обеспечивает взаимо- действие с restful API. Consul также предоставляет DNS-интерфейс для каждого клиента, что позволяет выполнять поиск доменных имен уз- лов, подключенных к кластеру. Демон consul-template – отдельный про- ект, который использует кластеры Consul; этот инструмент вырабаты- вает шаблоны файлов в ответ на изменения в узлах Consul, службах или парах ключ/значение. Это делает Consul очень мощным выбором для автоматизации NGINX. Используя consul-template, вы также можете дать демону указание выполнить команду после изменения шаблона. Благодаря этому можно перезагрузить конфигурацию NGINX и позво- лить оживить вашу конфигурацию наряду с вашей средой. С помощью Consul можно настроить проверку работоспособности для каждого кли- ента для проверки работоспособности предполагаемой службы. Благо- даря такому выявлению отказов можно соответствующим образом


 

74 v Глава 5. Программируемость и автоматизация                                                  

снабжать шаблонами свою конфигурацию NGINX, чтобы отправлять трафик только в жизнеспособные хосты.

См. также:

 
https://www.consul.io https://www.hashicorp.com/blog/introducing-consul-template.html https://github.com/hashicorp/consul-template

 

 

 


 


Глава 6


 

Аутентификация


6.0. Введение

 
NGINX может аутентифицировать клиентов. Запросы аутентификации клиента с помощью NGINX освобождают от лишней работы и предо- ставляют возможность останавливать запросы без аутентификации, чтобы они не доходили до ваших серверов приложений. Модули, до- ступные для NGINX с открытым исходным кодом, включают в себя ба- зовую аутентификацию и подзапросы аутентификации. Эксклюзивный модуль NGINX Plus для проверки веб-токенов JSON (JWT) обеспечивает интеграцию со сторонними поставщиками проверки подлинности, ко- торые используют стандарт аутентификации OpenID Connect.

6.1. Базовая HTTP-аутентификация

Задача

Вам необходимо защитить свое приложение или контент с помощью базовой HTTP-аутентификации.

Решение

Создайте файл в приведенном ниже формате, где пароль зашифро- ван или хеширован в одном из разрешенных форматов:

# comment name1:password1 name2:password2:comment name3:password3

 

Имя пользователя – это первое поле, пароль – второе поле, а разде- литель – это двоеточие. Существует необязательное третье поле, кото-


 

76 v Глава 6. Аутентификация                                                                                    

 
рое можно использовать для комментирования каждого пользователя. NGINX может понимать несколько различных форматов паролей, один из которых заключается в том, зашифрован ли пароль с помощью функ- ции языка С crypt(). Эта функция предоставляется командной строке командой openssl passwd. После установки openssl вы можете создавать зашифрованные строки пароля с помощью этой команды:

$ openssl passwd MyPassword1234

 

Выводом будет строка, которую NGINX может использовать в вашем файле пароля.

Используйте директивы auth_basic и auth_basic_user_file внутри своей конфигурации NGINX для активации базовой аутентификации:

location / {

auth_basic               "Private site"; auth_basic_user_file conf.d/passwd;

 
}

 

Вы можете использовать директивы auth_basic в контексте HTTP, сер- вера или местоположения. Директива auth_basic принимает строковый параметр, который отображается во всплывающем окне базовой аутен- тификации, при появлении пользователя без аутентификации. Файл auth_basic_user_file указывает путь к файлу пользователя.

Обсуждение

Вы можете создать пароли базовой аутентификации несколькими способами и в различных форматах с различной степенью безопас- ности. Команда htpasswd от Apache также может генерировать пароли. Команды openssl и htpasswd могут генерировать пароли с помощью ал- горитма apr1, который также способно понимать и NGINX. Пароль тоже может находиться в формате SHA-1, используемом протоколом LDAP и сервером Dovecot. NGINX поддерживает дополнительные форматы и алгоритмы хеширования; тем не менее многие из них считаются не- безопасными, потому что их можно легко взломать, применяя атаки методом грубого перебора.

Можно использовать базовую аутентификацию для защиты контекс-

та всего хоста NGINX, конкретных виртуальных серверов или даже прос- то определенных блоков location. Базовая аутентификация не заменит аутентификацию пользователя для веб-приложения, но может помочь защитить конфиденциальную информацию.


 

 
                                                                  6.2. Подзапросы аутентификации v 77

Под капотом базовая аутентификация выполняется сервером, возвра- щающим ошибку 401 unauthorized с заголовком ответа WWW-Authenticate. Этот заголовок будет иметь значение Basic realm = "ваша строка". Этот ответ заставляет браузер запрашивать имя пользователя и пароль. Имя пользователя и пароль объединяются и разделяются двоеточием, за- тем кодируются в base64 и отправляются в заголовке запроса с именем Authorization. В заголовке запроса Authorization будут указаны Basic и за- кодированная строка user: password. Сервер декодирует заголовок и све- ряется с auth_basic_user_file. Поскольку строка с паролем и именем поль- зователя закодирована всего лишь в кодировке base64, рекомендуется использовать протокол HTTPS с базовой аутентификацией.

6.2. Подзапросы аутентификации

Задача

У вас есть сторонняя система аутентификации, для которой вам нуж- ны аутентифицированные запросы.

Решение                                                   

Используйте http_auth_request_module, чтобы отправить запрос службе аутентификации для проверки личности перед обслуживанием запро- са:

location /private/ { auth_request                             /auth;

auth_request_set $auth_status $upstream_status;

}

 

location = /auth { internal;

proxy_pass                      http://auth-server; proxy_pass_request_body off; proxy_set_header                                          Content-Length "";

proxy_set_header          X-Original-URI $request_uri;

}

 

Директива auth_request принимает параметр URI, который дол- жен быть местным внутренним местоположением. Директива auth_ request_set позволяет установить переменные из подзапроса аутенти- фикации.


 

78 v Глава 6. Аутентификация                                                                                    

Обсуждение

 
 
Модуль  http_auth_request_module  активирует  аутентификацию  для каждого запроса, обрабатываемого сервером NGINX. Модуль выпол- няет подзапрос перед обработкой оригинала, чтобы определить, име- ет ли запрос доступ к ресурсу, который он запрашивает. Весь исходный запрос передается в это местоположение подзапроса. Местоположе- ние аутентификации действует как типичный прокси-сервер для под- запроса и отправляет исходный запрос, включая его тело и заголовки. Код состояния HTTP подзапроса определяет, будет ли предоставлен доступ. Если подзапрос возвращается с кодом состояния HTTP 200, аутентификация прошла успешно и запрос выполнен. Если подзапрос возвращает ошибку 401 или 403, то же самое будет возвращено для исходного запроса.

Если ваша служба аутентификации не запрашивает тело запроса,

можно удалить его с помощью директивы proxy_pass_request_body, как было продемонстрировано ранее. Используя такой метод, вы умень- шите размер запроса и время. Поскольку тело ответа отбрасывается, заголовок Content-Length должен быть установлен в пустую строку. Если вашей службе аутентификации нужно знать URI, к которому обращает- ся запрос, вам понадобится поместить это значение в настраиваемый заголовок, который ваша служба аутентификации проверяет и верифи- цирует. Если есть нечто, что вы хотите сохранить из подзапроса в служ- бу аутентификации, например заголовки ответа или другая информа- ция, можно использовать директиву auth_request_set для создания новых переменных из данных ответа.

6.3. Валидация токенов в формате JWT

Задача

Вам нужно проверить JWT-токен, прежде чем запрос будет обработан с помощью NGINX Plus.

Решение

Используйте модуль аутентификации на основе JWT от NGINX Plus, чтобы проверить подпись токена и встроить утверждения и заголовки JWT в качестве переменных NGINX:

location /api/ {

auth_jwt               "api";


 

                                                     6.4. Создание веб - ключей в формате JSON   v 79

auth_jwt_key_file conf/keys.json;

 
}

 

Данная конфигурация позволяет проверять токены JWT для этого местоположения. Директиве auth_jwt передается строка, которая ис- пользуется как область аутентификации. Директива auth_jwt принимает необязательный параметр токена переменной, которая содержит JWT. По умолчанию заголовок Authentication используется в соответствии со стандартом JWT. Директиву auth_jwt также можно использовать для от- мены эффектов требуемой аутентификации JWT из унаследованных конфигураций. Чтобы отключить аутентификацию, передайте клю- чевое слово в директиву auth_jwt без всего. Чтобы отменить унаследо- ванные требования аутентификации, передайте ключевое слово off в директиву auth_jwt, и ничего больше. auth_jwt_key_file  принимает один параметр, который является путем к файлу ключа в стандартном фор- мате JSON Web Key.

Обсуждение

 
NGINX Plus может проверять JWT-токены в отличие от типа веб-шиф- рования JSON, где весь токен шифруется. NGINX Plus может проверять сигнатуры, подписанные с помощью алгоритмов HS256, RS256 и ES256. Используя NGINX Plus для проверки токена, вы можете сэкономить вре- мя и ресурсы, необходимые для создания подзапроса к службе аутенти- фикации.

NGINX Plus расшифровывает заголовок и полезную нагрузку JWT, а

также подставляет значения стандартных заголовков и заявок во встро- енные переменные, которые вы применяете.

См. также:

https://tools.ietf.org/html/rfc7515

https://tools.ietf.org/html/rfc7518

https://tools.ietf.org/html/rfc7519 http://nginx.org/en/docs/http/ngx_http_auth_jwt_module.html#variables https://www.nginx.com/blog/authenticating-api-clients-jwt-nginx-plus/

 

6.4. Создание веб-ключей в формате JSON

Задача

Вам нужен ключ в формате JSON для использования в NGINX Plus.


 

80 v Глава 6. Аутентификация                                                                              

Решение

NGINX Plus использует формат JSON Web Key (JWK), как указано в стандарте RFC. Этот стандарт допускает массив ключей объектов в фай- ле JWK.

Ниже приводится пример того, как может выглядеть файл ключа:

{"keys":                                                       

[

{

"kty":"oct",

"kid":"0001",

"k":"OctetSequenceKeyValue"

},

{

"kty":"EC",

"kid":"0002"

"crv":"P-256",

 
"x": "XCoordinateValue", "y": "YCoordinateValue", "d": "PrivateExponent", "use": "sig"

},

{

"kty":"RSA",

"kid":"0003"

"n": "Modulus",

"e": "Exponent",

"d": "PrivateExponent"

}

]

}

 

Показанный файл JWK демонстрирует три начальных типа ключей, отмеченных в стандарте RFC. Формат этих ключей также является ча- стью стандарта RFC. Атрибут kty – это тип ключа. В этом файле показа- ны три типа ключей: Octet Sequence (oct), EllipticCurve (EC) и тип RSA. Атрибут kid – это идентификатор ключа. Другие атрибуты этих ключей указаны в стандарте для этого типа ключа. Обратитесь к документации RFC для получения дополнительной информации.


Дата добавления: 2021-01-21; просмотров: 126; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!