Как защитить доступ администратора к Apache APISIX
14 февраля 2023 г.Шлюзы API являются важными компонентами инфраструктуры. Если бы злоумышленник мог изменить конфигурацию маршрутов, он мог бы направить трафик в свою инфраструктуру. Последствия могут варьироваться от кражи данных до финансовых потерь.
Хуже того, кражу данных можно было заметить только по прошествии длительного времени путем зеркалирования нагрузки. Следовательно, защита шлюза API имеет первостепенное значение.
В этом коротком сообщении в блоге я перечислю несколько способов защиты доступа администратора Apache APISIX.
Изменить токены администратора
Вы можете управлять конфигурацией Apache APISIX через его HTTP API. Токен защищает каждый вызов API. Для операций требуется HTTP-заголовок X-API-KEY:
* Используйте токен с ролью viewer для вызова операций чтения
* Используйте токен с ролью admin для вызова операций чтения и записи
.Например, чтобы создать новый маршрут, мне нужно передать токен роли admin, который позволяет вызывать операции записи:
curl http://localhost:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"methods": ["GET"],
"uri": ["/hello"],
"upstream_id": 1
}'
Первым и главным шагом для защиты вашего доступа является изменение значений токена по умолчанию:
deployment:
admin:
# Default token when use API to call for Admin API.
# *NOTE*: Highly recommended to modify this value to protect APISIX's Admin API.
# Disabling this configuration item means that the Admin API does not
# require any authentication.
admin_key:
- name: admin
key: edd1c9f034335f136f87ad84b625c8f1 #1
role: admin # admin: manage all configuration data
# viewer: only can view configuration data
- name: viewer
key: 4054f7cf07e344346cd3f287985e76a2 #1
role: viewer
- Измени это!
Вы можете захотеть еще больше обезопасить токены; это зависит от вашей платформы. Например, вы можете сохранить токены как Secret и внедрить их при запуске контейнера.
Ограничить связывание IP-адресов
Сервер может иметь несколько IP-адресов от разных сетевых адаптеров. Например, шлюз API должен иметь как минимум два сетевых адаптера:
* Один общедоступный адаптер должен быть доступен из Интернета
* Один внутренний для доступа внутрь
По умолчанию Apache APISIX привязывается ко всем сетевым адаптерам, найденным на сервере при запуске. Приведенный выше сценарий означает, что он будет доступен из Интернета. Мы должны ограничить доступ только изнутри.
Мы можем указать, к какому сетевому интерфейсу Apache APISIX может привязываться в конфигурации:
deployment:
admin:
admin_listen:
ip: 0.0.0.0 # Specific IP, if not set, the default value is `0.0.0.0` #1
- Измени это!
Ограничить разрешенные IP-адреса
Даже если вы ограничиваете доступ только к IP-адресам внутри вашей корпоративной сети, вы хотите, чтобы только некоторые компьютеры имели доступ к конфигурации шлюза API. Если бы это было так, злоумышленник, получивший доступ к компьютеру бухгалтера, мог бы использовать его, чтобы попытаться атаковать шлюз API.
Вы можете ограничить IP-доступ с помощью сетевых политик — и вы должны это сделать. Однако вы также можете применить это ограничение к шлюзу API: он может обеспечить более точный контроль и более гибкие изменения — в целом сетевые политики трудно изменить.
Вот соответствующий фрагмент для Apache APISIX:
deployment:
admin:
allow_admin:
- 127.0.0.0/24 # If we don't set any IP list, then any IP access is allowed by default
#- "::/64" #1
- Измените его в соответствии с топологией вашей сети.
Взаимный TLS
Если говорить об аутентификации, то один из способов — цифровой сертификат. На сегодняшний день самым распространенным механизмом низкоуровневой аутентификации является Transport Layer Security. TLS позволяет серверам подтверждать свою личность.
Кроме того, он обеспечивает конфиденциальность передаваемых данных и предотвращает их подделку.
Взаимный TLS работает с обеих сторон, так что сервер подтверждает свою личность клиенту, и клиент подтверждает свою личность серверу.
Вот соответствующий фрагмент конфигурации для установки административного mTLS в Apache APISIX:
deployment:
admin:
https_admin: true # enable HTTPS when use a separate port for Admin API
# Admin API will use conf/apisix_admin_api.crt and conf/apisix_admin_api.key as certificate
admin_api_mtls:
admin_ssl_ca_cert: "/data/certs/mtls_ca.crt" # Path of your self-signed ca cert
admin_ssl_cert: "/data/certs/mtls_server.crt" # Path of your self-signed server side cert
admin_ssl_cert_key: "/data/certs/mtls_server.key" # Path of your self-signed server side key
Автономный режим
И последнее, но не менее важное: можно полностью перенести конфигурацию из etcd в статический файл (YAML). В этом случае API администратора недоступен для обновления конфигурации. Эта модель развертывания известна как автономный режим.
В автономном режиме единственным способом изменить конфигурацию является обновление статического файла: Apache APISIX будет регулярно проверять наличие изменений и соответствующим образом обновлять себя. Это отличный способ применить принципы GitOps с помощью Apache APISIX.
Тем временем вы можете настроить автономный режим следующим образом:
deployment:
role: data_plane
role_data_plane:
config_provider: yaml
Обратите внимание, что в автономном режиме все другие варианты защиты становятся спорными, так как больше нет Admin API для защиты.
Заключение
Вам необходимо защитить шлюзы API от нежелательного доступа, поскольку они являются ценными целями для злоумышленников. В этом посте я показал несколько неисключительных вариантов, которые вы должны рассмотреть для защиты Apache APISIX.
Наконец, я описал, как это можно сделать без Admin API с помощью выделенного автономного режима развертывания. Ожидайте в будущем пост в блоге о том, как использовать его с GitOps.
Дальше:
Первоначально опубликовано на сайте A Java Geek 5 февраля 2023 г.
Оригинал