0

我有一个 Nifi 和一个 Nifi-Registry 都在 docker + docker-compose 之上的 Nginx 代理后面的两个不同 AWS EC2 实例上运行。在 HTTP 上运行良好，但不安全。

现在我试图让事情更安全一点：

  1. 使用自签名 SSL/TLS 证书保护 Nifi-Registry
  2. 从浏览器访问 Nifi-Registry 时添加基本身份验证。
  3. 使用客户端-服务器证书确保客户端-服务器（nifi <-> nifi-registry）之间的通信安全。

我遇到了 Michal Klempa 的这篇https://michalklempa.com/2019/04/nifi-registry-nginx-proxy-tls-basic-auth/ 博客文章。按照上面链接中描述的方法，我在访问 https://[MY-NIFI-REG-HOST].com:18433/nifi-registry 时设法获得了基本身份验证的 Nifi-Registry 请求。下一步是让 Nifi 绕过客户端-服务器证书身份验证。

我已将 https://[MY-NIFI-REG-HOST].com:18433 作为“注册表客户端”添加到 Nifi 控制器设置。但是，当我尝试在其中一个 Nifi 处理器组上启动版本控制时，我收到以下错误：

身份验证 401 错误

看起来 Nifi 未能使用其客户端证书在 Nifi-Registry 实例上对 Nginx 进行身份验证，因此 Nginx 回复 401。

我试过几次按照说明进行操作，但我不确定我哪里出错了。

这是我的 Nifi-Registry 实例 docker-compose.yaml 配置和 Nginx 反向代理设置：

version: '3.4'

services:
   nginx:
      image: nginx:latest
      container_name: nginx
      restart: always
      depends_on:
       - nifi_registry
      ports:
       - 18443:18443
      volumes:
       - ~/nginx/conf.d/default.conf:/etc/nginx/conf.d/default.conf
       - ~/nginx/server_cert.pem:/etc/nginx/server_cert.pem
       - ~/nginx/server_key.pem:/etc/nginx/server_key.pem
       - ~/nginx/client_cert.pem:/etc/nginx/client_cert.pem
       - ~/nginx/htpasswd:/etc/nginx/htpasswd
      networks:
       - static-network

   nifi_registry:
      image: apache/nifi-registry:latest
      restart: always
      container_name: nifi-registry
      ports:
       - 18080:18080
      environment:
       - NIFI_REGISTRY_WEB_HTTP_HOST=0.0.0.0
      networks:
       - static-network

volumes:
   share_dir: {}

networks:
  static-network:
    ipam:
      config:
        - subnet: 172.20.0.0/16

Nginx default.conf 与作者博客文章中的相同：

server {
  listen 18443 ssl;

  root /usr/share/nginx/html;

  index index.html;

  server_name _;

  ssl_certificate /etc/nginx/server_cert.pem;
  ssl_certificate_key /etc/nginx/server_key.pem;

  ssl_client_certificate /etc/nginx/client_cert.pem;
  ssl_verify_client optional;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  # enables server-side protection from BEAST attacks
  ssl_prefer_server_ciphers on;

  # Disabled insecure ciphers suite. For example, MD5, DES, RC4, PSK
  ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:@STRENGTH";

  # -!MEDIUM：exclude encryption cipher suites using 128 bit encryption.
  # -!LOW：   exclude encryption cipher suites using 64 or 56 bit encryption algorithms
  # -!EXPORT： exclude export encryption algorithms including 40 and 56 bits algorithms.
  # -!aNULL：  exclude the cipher suites offering no authentication. This is currently the anonymous DH algorithms and anonymous ECDH algorithms.
  # These cipher suites are vulnerable to a "man in the middle" attack and so their use is normally discouraged.
  # -!eNULL：exclude the "NULL" ciphers that is those offering no encryption.
  # Because these offer no encryption at all and are a security risk they are disabled unless explicitly included.
  # @STRENGTH：sort the current cipher list in order of encryption algorithm key length.

  location / {
    if ($ssl_client_verify = SUCCESS) {
      set $auth_basic off;
    }
    if ($ssl_client_verify != SUCCESS) {
      set $auth_basic "Restricted Content";
    }

    auth_basic $auth_basic;
    auth_basic_user_file /etc/nginx/htpasswd;

    proxy_pass    http://nifi-registry:18080;
    proxy_set_header   Host                 $host;
    proxy_set_header   X-Real-IP            $remote_addr;
    proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto    $scheme;
    proxy_set_header   X-Forwarded-User     $remote_user;
    proxy_set_header   Authorization        "";
    proxy_set_header   X-ProxyScheme        $scheme;
    proxy_set_header   X-ProxyHost          $hostname;
    proxy_set_header   X-ProxyPort          $server_port;
    proxy_set_header   X-ProxyContextPath   /;
  }
}

在 Nifi 实例上，如博客文章中所述，我已将CA 签名的文件client_keystore.p12和client_trustorestore.p12所需文件复制到 nifi docker 容器中nifi.properties

我想我错过了一些东西，或者客户端-服务器证书不匹配......希望有人能指出这一点。

4

0 回答 0