Грабли при обновлении ingress-nginx до 1.12.1

Вчера срочно обновлял ingress-nginx до 1.12.1 (версия чарта 4.12.1) после новости о критической уязвимости CVE-2025-1974 и наступил на грабли - релиз обновился, но все существующие ingress'ы потеряли привязку к IP адресу балансировщика.

Полез смотреть events в кластере, но там ничего криминального не нашлось. В логах ingress-nginx контроллера присутствовали ошибки вида

E0325 12:26:36.275715       7 store.go:938] annotation group ConfigurationSnippet contains risky annotation based on ingress configuration

но сходу у меня не сложилась связь этих ошибок с отсутствием привязки к IP адресу. А вот когда попробовал пересоздать один из ingress'ов всё стало на свои места

Error: INSTALLATION FAILED: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: annotation group ConfigurationSnippet contains risky annotation based on ingress configuration

Во всех ингресах присутствовала аннотация nginx.ingress.kubernetes.io/configuration-snippet через которую делается тонкий тюнинг приложений и нет простого способа отказаться от использования этой опции.

Чтобы не путаться в сортах Nginx ingress

Нужно помнить что в мире Kubernetes есть два варианта nginx ingress, которые можно спутать:

• ingress-nginx (аннотации)
  
• nginx-ingress (аннотации)

В самом кластере их можно опознать по контроллеру в ingressclass:

• k8s.io/ingress-nginx - это ingress-nginx
• nginx.org/ingress-controller - это nginx-ingress
  

Назначение префикса URI для веб сервисов

Эта история из разряда "как не нужно делать". Изначально не планировал ее писать, но потратил некоторое количество времеми и хочется предостеречь других от хождения по граблям.

Имеется набор веб сервисов в которых не реализована настройка префикса URI, т.е. все ссылки строятся относительно "корня" (например: hostname:port/login, hostname:port/public/script.js, и т.д.).

И есть желание проверить сможет ли Nginx прозрачно проксировать запросы добавляя префикс каждому сервису чтобы не пришлось менять внутренности самих сервисов.

Сразу скажу что существует более надежное и простое решение - дать каждому сервису собственный поддомен, но это бывает сложно с точки зрения процессов: одобрение доменных имён, новые записи в DNS, SSL сертификаты и т.д.

Nginx запрашивает / вместо /.well-known/openid-configuration

Настраиваю workload identity federation между on-prem GitLab и GCP согласно документации. Сделал настройки в GCP, взял готовый пример пайплайна, но джоба падает с ошибкой

$ gcloud auth print-access-token
ERROR: (gcloud.auth.print-access-token) ("Error code invalid_grant: Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected '{']", '{"error":"invalid_grant","error_description":"Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected \'{\']"}')

Смотрю что выдаёт https://GITLAB/.well-known/openid-configuration и вижу 302 редирект на /users/sign_in - это неожиданное поведение. На этот запрос должно возвращать JSON вида

$ curl -s https://gitlab.com/.well-known/openid-configuration
{"issuer":"https://gitlab.com","authorization_endpoint":"https://gitlab.com/oauth/authorize","token_endpoint":"https://gitlab.com/oauth/token","revocation_endpoint":"https://gitlab.com/oauth/revoke","introspection_endpoint":"https://gitlab.com/oauth/introspect","userinfo_endpoint":"https://gitlab.com/oauth/userinfo","jwks_uri":"https://gitlab.com/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Нужно разобраться откуда у меня берется этот редирект.

Будьте внимательны при апгрейде Nginx + PHP-fpm в Debian Jessie

При обновлении хоста с Debian Jessie столкнулся с полностью нерабочими PHP сайтами после завершения апгрейда сервера. На любой запрос php скрипта веб-сервер просто отвечает HTTP 200 и отдает пустую страницу. Никаких ошибок в логе Nginx не было.

Сайты содержали следующий кусок конфига:

location ~ \.php$ {

  # skipped lines

  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_index index.php;
  include fastcgi_params;
}

В процессе дебага выяснилось, что из файла /etc/nginx/fastcgi_params выкинули объявление параметра SCRIPT_FILENAME и из-за этого интерпретатору срывает крышу. Случилось это в районе версии 1.6.1-2:

  * debian/conf/fastcgi_params:
    + Sync with upstream and remove `SCRIPT_FILENAME` parameter.
      This change might break fastcgi sites. (Closes: #718639)
  + debian/conf/fastcgi.conf:
    + Ship upstream file.

Теперь в Nginx включен пример конфигурации для PHP-fpm (/etc/nginx/snippets/fastcgi-php.conf)

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

P.S. Особая благодарность создателям socat - он мой новый лучший друг в вопросах отладки. Достаточно запустить

socat -v UNIX-LISTEN:/tmp/php5-debug.sock UNIX-CONNECT:/var/run/php5-fpm.sock

и перенастроить Nginx на подключение к /tmp/php5-debug.sock, как становится виден процесс общения Nginx и PHP-fpm, а соответственно и суть проблемы.

Nginx: запаролить доступ к директории с PHP скриптами

Очень удивился когда Nginx дал выполнить скрипт из запароленной директории. При этом на саму директорию пароль спрашивает.

Этот ответ прояснил ситуацию. Полное описание логики блока location.

Nginx: client intended to send too large body

Если в логи nginx падает ошибка вида

2014/03/11 11:54:28 [error] 8699#0: *4615315 client intended to send too large body: 1569729 bytes, client: xx.xx.xx.xx, server: example.com, request: "POST /upload/index.php HTTP/1.1", host: "example.com", referrer: "http://example.com/upload/"

То причина в превышении лимита размера тела запроса в Nginx, за этот лимит отвечает параметр client_max_body_size (по-умолчанию лимит равен 1m).

Чтобы увеличить этот лимит хотя бы до 50m добавьте в конфигурацию nginx (в Debian это можно сделать через файл /etc/nginx/conf.d/local.conf)

# echo 'client_max_body_size 50m;' > /etc/nginx/conf.d/local.conf
# nginx -t
the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful
# service nginx reload

P.S. Ответ нашелся тут.

Включение maintenance режима в Nginx без помощи системного администратора

Вчера реализовал новую, более удобную для разработчиков, возможность перевести сайт в maintenance режим для всех посетителей, кроме тех, кто заходит с определенных ip (сайт всегда доступен самим разработчикам).

Имеем два ip адреса, с которых нужно пускать клиентов независимо от текущего режима сайта (для примера 67.81.43.124 и 67.23.44.5). Чтобы для включения maintenance режима не нужно было дергать администратора, будем считать наличие файла maintenance.flag в корне сайта, признаком включения maintenance режима.

Я использую nginx из Debian Squeeze и примеры будут ориентированы на него.

Для поддержки нового режима я добавил несколько секций в /etc/nginx/sites-enabled/www.example.com

geo $show_maintenance_page {
    default yes;
    67.81.43.124 no;
    67.23.44.5 no;
}

server {
    listen 80;
    server_name www.example.com example.com;

    if ( -f /var/www/www.example.com/maintenance.flag ) {
        set $maintenance y;
    }

    if ( $show_maintenance_page = yes ) {
        set $maintenance y$maintenance;
    }

    if ( $maintenance = yy ) {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        root /var/www/maintenance;
        rewrite ^(.*)$ /maintenance.html break;
    }

    # All other config

}

Содержимое /var/www/maintenance у меня существует еще с прежнего варианта, который я описывал ранее. Теперь чтобы перевести сайт в режим maintenance нужно создать файл maintenance.flag в корне сайта (/var/www/www.example.com). После этого всем посетителям будет выдавать maintenance страницу, а для тех, кто заходит с адресов 67.81.43.124 или 67.23.44.5 будет доступен сайт. Чтобы выключить maintenance достаточно удалить файл maintenance.flag.

Maintenance page для сайтов, которые обслуживаются Nginx

Вчера потребовалось отключить пару сайтов, которые обслуживаются Nginx. В загашнике у меня есть папка maintenance, которую я кладу на место исходников, когда нужно быстро отключить сайт.

<html>
<head>
<title>Server Maintenance</title>
</head>
<body>
<center>
<h1>Server maintenance</h1>
Our apologies for the temporary inconvenience. The page is temporarily unavailable as server is down for scheduled maintenance. We will be back soon.
</center>
</body>
</html>

/var/www/maintenance/maintenance.html

<IfModule mod_rewrite.c>
    RewriteEngine on

    RewriteCond %{REQUEST_URI} !^/maintenance.html$
    RewriteRule .* /maintenance.html [R=302,L]
</IfModule>

/var/www/maintenance/.htaccess

Это позволяет отключать сайты вот так:

$ mv /path/to/siteroot /path/to/siteroot~disabled && \
cp -a /path/to/maintenance /path/to/siteroot

Этот способ хорош для apache, который обрабатывает .htaccess. Для Nginx поступил иначе:

• Поместил директорию maintenance в /var/www
• Создал конфиг /etc/nginx/maintenance-page
  

  location / {
      return 503;
  }
  
  error_page 503 /maintenance.html;
  
  location /maintenance.html {
      internal;
      root /var/www/maintenance;
  }

  /etc/nginx/maintenance-page
  
• Теперь чтобы отключить сайт /etc/nginx/sites-enabled/example.com (symlink на /etc/nginx/sites-available/example.com), нужно:
  

  # rm -f /etc/nginx/sites-enabled/example.com
  # cat > /etc/nginx/sites-available/example.com~maintenance <<EOF
  server {
      listen 80;
      server_name example.com;
      include /etc/nginx/maintenance-page;
  }
  EOF
  
  # ln -s /etc/nginx/sites-{available,enabled}/example.com~maintenance

• Остается перечитать конфиг в Nginx
  

  nginx -t && nginx -s reload

UPDATE: В комментариях подсказали более простой (и скорее всего более быстрый) способ для maintenance страницы. Поправил код в посте. Директива internal в секции location не даст напрямую обращаться к /maintenance.html.