Apache NiFi系统管理员指南 [ 一 ]

如何安装和启动NiFi端口配置NiFi嵌入式Zookeeper配置最佳实践安全配置TLS生成工具包用户认证轻量级目录访问协议（LDAP）Kerberos的OpenId ConnectApache Knox多租户授权授权人配置Authorizers.xml安装程序Apache NiFi团队dev@nifi.apache.org...

张伯毅

4971人浏览 · 2019-03-20 16:03:05

张伯毅 · 2019-03-20 16:03:05 发布

Apache NiFi团队dev@nifi.apache.org

系统要求

Apache NiFi可以运行在像笔记本电脑这样简单的东西上，但它也可以集群在许多企业级服务器上。因此，所需的硬件和内存量将取决于所涉及的数据流的大小和性质。在NiFi处理数据时，数据存储在磁盘上。因此，NiFi需要为其各种存储库分配足够的磁盘空间，尤其是内容存储库，流文件存储库和源文件存储库（有关这些存储库的更多信息，请参阅“ 系统属性”部分）。NiFi具有以下最低系统要求：

需要Java 8或更高版本
支持的操作系统：
- Linux的
- Unix的
- 视窗
- Mac OS X.
支持的Web浏览器：
- Microsoft Edge： Current & (Current - 1)
- Mozilla FireFox： Current & (Current - 1)
- Google Chrome： Current & (Current - 1)
- Safari： Current & (Current - 1)

注意在持续且极高的吞吐量下，可能需要调整CodeCache设置以避免突然的性能损失。有关更多信息，请参阅Bootstrap Properties部分。

如何安装和启动NiFi

Linux / Unix / OS X.
- 解压缩并解压缩到所需的安装目录
- 在下面找到的文件中进行任何所需的编辑 <installdir>/conf
  - 至少，我们建议您编辑nifi.properties文件并输入密码nifi.sensitive.props.key（请参阅下面的系统属性）
- 从<installdir>/bin目录中，键入以下命令执行以下命令./nifi.sh <command>：
  - start：在后台启动NiFi
  - stop：停止在后台运行的NiFi
  - status：提供NiFi的当前状态
  - run：在前台运行NiFi并等待Ctrl-C启动NiFi的关闭
  - install：安装NiFi作为服务，然后可以通过控制
    - service nifi start
    - service nifi stop
    - service nifi status
视窗
- 解压缩到所需的安装目录
- 在下面的文件中进行任何所需的编辑 <installdir>/conf
  - 至少，我们建议您编辑nifi.properties文件并输入密码nifi.sensitive.props.key（请参阅下面的系统属性）
- 导航到该<installdir>/bin目录
- 双击run-nifi.bat。这会在前台运行NiFi并等待Ctrl-C启动NiFi的关闭
- 要查看NiFi的当前状态，请双击 status-nifi.bat

首次启动NiFi时，会创建以下文件和目录：

content_repository
database_repository
flowfile_repository
provenance_repository
work 目录
logs 目录
在conf目录中，将创建flow.xml.gz文件

有关配置NiFi存储库和配置文件的详细信息，请参阅本指南的“ 系统属性”部分。

端口配置

NiFi

下表列出了NiFi使用的默认端口以及nifi.properties文件中的相应属性。

功能	属性	默认值
Web HTTP Forwarding Port	`nifi.web.http.port.forwarding`	none
HTTP Port	`nifi.web.http.port`	`8080`
HTTPS Port*	`nifi.web.https.port`	`9443`
Remote Input Socket Port*	`nifi.remote.input.socket.port`	`10443`
Cluster Node Protocol Port*	`nifi.cluster.node.protocol.port`	`11443`
Cluster Node Load Balancing Port	`nifi.cluster.node.load.balance.port`	`6342`

标有星号（*）的端口的属性值默认为nifi.properties中的空白。当使用TLS Toolkit为安全的NiFi实例生成nifi.properties时，表中显示的值是这些端口的默认值。TLS Toolkit使用的默认证书颁发机构端口是8443。

嵌入式Zookeeper

下表列出了Embedded ZooKeeper服务器使用的默认端口以及zookeeper.properties文件中的相应属性。

功能	属性	默认值
Zookeeper Server Quorum and Leader Election Ports	`server.1`	没有
Zookeeper Client Port	`clientPort`	`2181`

Zookeeper服务器端口的注释示例包含在表单中的zookeeper.properties文件中server.N=nifi-nodeN-hostname:2888:3888。

配置最佳实践

如果您在Linux上运行，请考虑这些最佳实践。典型的Linux默认设置不一定能够满足像NiFi这样的IO密集型应用程序的需求。对于所有这些领域，您的分发要求可能会有所不同。使用这些部分作为建议，但请参阅特定于发行版的文档，以了解如何最好地实现这些建议。

最大文件句柄(Maximum File Handles)

NiFi在任何时候都可能会打开非常大量的文件句柄。通过编辑/etc/security/limits.conf来增加限制，以添加类似的内容

* hard nofile 50000
* soft nofile 50000

最大Forked Processes

NiFi可以配置为生成大量线程。要增加允许的数量，请编辑/etc/security/limits.conf

*  hard  nproc  10000
*  soft  nproc  10000

您的发行版可能需要通过添加来编辑/etc/security/limits.d/90-nproc.conf

* soft nproc 10000

增加可用的TCP套接字端口数

如果您的流量将在很短的时间内设置并拆除大量socket ，这一点尤为重要。

sudo sysctl -w net.ipv4.ip_local_port_range =“10000 65000”

设置套接字在关闭时保持TIMED_WAIT状态的时间 (Set how long sockets stay in a TIMED_WAIT state when closed)

考虑到您希望能够快速设置和拆卸新套接字，您不希望您的套接字停留太长时间。最好多阅读一下并调整类似的东西

sudo sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait =“1”

告诉Linux你永远不希望NiFi交换

对于某些应用程序来说，交换非常棒。对于像NiFi一样想要运行的东西并不好。要告诉Linux你要换掉，你可以编辑/etc/sysctl.conf来添加以下行

vm.swappiness = 0

对于处理各种NiFi回购的分区，请关闭类似atime的东西。这样做会导致吞吐量出人意料地大幅增加。编辑/etc/fstab文件和感兴趣的分区，添加noatime选项。

安全配置

NiFi提供多种不同的配置选项以用于安全目的。最重要的属性是nifi.properties文件中“安全属性”标题下的属性。为了安全运行，必须设置以下属性：

物业名称	描述
`nifi.security.truststorePasswd`	Truststore的密码。
`nifi.security.keystore`	包含服务器私钥的密钥库的文件名。
`nifi.security.keystoreType`	密钥库的类型。必须是`PKCS12`或`JKS`。JKS是首选类型，PKCS12文件将加载BouncyCastle提供程序。
`nifi.security.keystorePasswd`	密钥库的密码。
`nifi.security.keyPasswd`	密钥库中证书的密码。如果未设置，`nifi.security.keystorePasswd`将使用值。
`nifi.security.truststore`	将用于授权连接到NiFi的Truststore的文件名。没有Truststore的安全实例将拒绝所有传入连接。
`nifi.security.truststoreType`	Truststore的类型。必须是`PKCS12`或`JKS`。JKS是首选类型，PKCS12文件将加载BouncyCastle提供程序。

一旦配置了上述属性，我们就可以通过HTTPS而不是HTTP来访问用户界面。这是通过设置nifi.web.https.host和nifi.web.https.port属性来完成的。该nifi.web.https.host属性指示服务器应在哪个主机名上运行。如果希望可以从所有网络接口访问HTTPS接口，0.0.0.0则应使用值。允许管理员将应用程序配置为仅在特定网络接口上运行，nifi.web.http.network.interface*或者nifi.web.https.network.interface* 可以指定属性。

启用HTTPS时重要的nifi.web.http.port是取消设置属性。NiFi仅支持在HTTP 或 HTTPS 上运行，而不是同时支持。

当没有配置需要单向SSL（例如LDAP，OpenId Connect等）的替代认证机制时，NiFi的Web服务器将要求访问用户界面的用户使用基于证书的客户端身份验证。启用备用身份验证机制会将Web服务器配置为WANT证书基本客户端身份验证。这将允许它支持具有证书的用户，而没有证书的用户可以使用凭证登录。有关详细信息，请参阅用户验证

既然用户界面已经受到保护，我们也可以轻松保护站点到站点的连接和内部群集通信。这是通过分别设置nifi.remote.input.secure和nifi.cluster.protocol.is.secure属性来实现的true。这些通信将始终需要双向SSL，因为节点将使用其配置的密钥库/信任库进行身份验证。

TLS生成工具包

为了便于NiFi的安全设置，您可以使用tls-toolkit命令行实用程序自动生成所需的密钥库，信任库和相关配置文件。这对于保护多个NiFi节点特别有用，这可能是一个单调乏味且容易出错的过程。有关更多信息，请参阅NiFi工具包指南中的TLS工具包部分。相关主题包括：

用户认证

NiFi通过客户端证书，用户名/密码，Apache Knox或OpenId Connect支持用户身份验证。

用户名/密码验证由“登录身份提供者”执行。登录身份提供程序是一种可插入的机制，用于通过用户名/密码对用户进行身份验证。要在nifi.properties文件中配置要使用的登录标识提供程序。目前，NiFi为轻量级目录访问协议（LDAP）和Kerberos提供了用户名/密码和登录身份提供商选项。

该nifi.login.identity.provider.configuration.file属性指定登录标识提供程序的配置文件。默认情况下，此属性设置为./conf/login-identity-providers.xml。

该nifi.security.user.login.identity.provider属性指示应使用哪个配置的登录标识提供程序。默认情况下，未配置此属性意味着必须明确启用用户名/密码。

在OpenId Connect身份验证期间，NiFi会在返回NiFi之前将用户重定向到使用提供商登录。然后，NiFi将致电提供商以获取用户身份。

在Apache Knox身份验证期间，NiFi将重定向用户以使用Apache Knox登录，然后再返回NiFi。NiFi将在身份验证期间验证Apache Knox令牌。

NiFi只能在给定时间配置为用户名/密码，OpenId Connect或Apache Knox。它不支持同时运行这些中的每一个。如果没有配置这些，则NiFi将要求客户端证书通过HTTPS对用户进行身份验证。

除非配置为使用轻量级目录访问协议（LDAP）或Kerberos登录身份提供程序，否则无法匿名访问受保护的NiFi实例，而后者必须配置为明确允许匿名访问。默认的FileAuthorizer目前无法进行匿名访问（请参阅授权器配置），但这是未来的努力（NIFI-2730）。

NiFi不通过HTTP执行用户身份验证。使用HTTP，所有用户都将被授予所有角色。

轻量级目录访问协议（LDAP）

以下是配置登录身份提供程序的示例和说明，该登录身份提供程序与Directory Server集成以对用户进行身份验证。

在nifi.properties中设置以下内容以启用LDAP用户名/密码身份验证：

nifi.security.user.login.identity.provider=ldap-provider

修改login-identity-providers.xml以启用ldap-provider。以下是文件中提供的示例：

<provider>
    <identifier>ldap-provider</identifier>
    <class>org.apache.nifi.ldap.LdapProvider</class>
    <property name="Authentication Strategy">START_TLS</property>

    <property name="Manager DN"></property>
    <property name="Manager Password"></property>

    <property name="TLS - Keystore"></property>
    <property name="TLS - Keystore Password"></property>
    <property name="TLS - Keystore Type"></property>
    <property name="TLS - Truststore"></property>
    <property name="TLS - Truststore Password"></property>
    <property name="TLS - Truststore Type"></property>
    <property name="TLS - Client Auth"></property>
    <property name="TLS - Protocol"></property>
    <property name="TLS - Shutdown Gracefully"></property>

    <property name="Referral Strategy">FOLLOW</property>
    <property name="Connect Timeout">10 secs</property>
    <property name="Read Timeout">10 secs</property>

    <property name="Url"></property>
    <property name="User Search Base"></property>
    <property name="User Search Filter"></property>

    <property name="Identity Strategy">USE_DN</property>
    <property name="Authentication Expiration">12 hours</property>
</provider>

将ldap-provider具有以下特性：

物业名称	描述
`Authentication Expiration`	用户身份验证有效期的持续时间。如果用户从未注销，则需要在此持续时间之后重新登录。
`Authentication Strategy`	如何验证与LDAP服务器的连接。可能的值是`ANONYMOUS`，`SIMPLE`，`LDAPS`，或`START_TLS`。
`Manager DN`	用于绑定到LDAP服务器以搜索用户的管理器的DN。
`Manager Password`	用于绑定到LDAP服务器以搜索用户的管理器的密码。
`TLS - Keystore`	使用LDAPS或START_TLS连接到LDAP时使用的密钥库的路径。
`TLS - Keystore Password`	使用LDAPS或START_TLS连接到LDAP时使用的密钥库的密码。
`TLS - Keystore Type`	使用LDAPS或START_TLS（即`JKS`或`PKCS12`）连接到LDAP时使用的密钥库的类型。
`TLS - Truststore`	使用LDAPS或START_TLS连接到LDAP时使用的Truststore的路径。
`TLS - Truststore Password`	使用LDAPS或START_TLS连接到LDAP时使用的Truststore的密码。
`TLS - Truststore Type`	使用LDAPS或START_TLS（即`JKS`或`PKCS12`）连接到LDAP时使用的Truststore的类型。
`TLS - Client Auth`	使用LDAPS或START_TLS连接到LDAP时的客户端身份验证策略。可能的值是`REQUIRED`，`WANT`，`NONE`。
`TLS - Protocol`	使用LDAPS或START_TLS连接到LDAP时使用的协议。（即`TLS`，`TLSv1.1`，`TLSv1.2`，等等）。
`TLS - Shutdown Gracefully`	指定在关闭目标上下文之前是否应正常关闭TLS。默认为false。
`Referral Strategy`	处理推荐的策略。可能的值是`FOLLOW`，`IGNORE`，`THROW`。
`Connect Timeout`	连接超时的持续时间。（即`10 secs`）。
`Read Timeout`	读取超时的持续时间。（即`10 secs`）。
`Url`	以空格分隔的LDAP服务器的URL列表（即`ldap://<hostname>:<port>`）。
`User Search Base`	用于搜索用户的基本DN（即`CN=Users,DC=example,DC=com`）。
`User Search Filter`	过滤搜索用户`User Search Base`。（即`sAMAccountName={0}`）。用户指定的名称将插入“{0}”。
`Identity Strategy`	识别用户的策略。可能的值是`USE_DN`和`USE_USERNAME`。缺少此属性的默认功能是USE_DN，以保持向后兼容性。`USE_DN`将尽可能使用用户条目的完整DN。`USE_USERNAME`将使用用户登录的用户名。

要使对nifi.properties和login-identity-providers.xml的更改生效，需要重新启动NiFi。如果NiFi是群集的，则所有节点上的配置文件必须相同。

Kerberos的

以下是配置登录身份提供程序的示例和说明，该登录身份提供程序与Kerberos密钥分发中心（KDC）集成以对用户进行身份验证。

在nifi.properties中设置以下内容以启用Kerberos用户名/密码身份验证：

nifi.security.user.login.identity.provider=kerberos-provider

修改login-identity-providers.xml以启用kerberos-provider。以下是文件中提供的示例：

<provider>
    <identifier>kerberos-provider</identifier>
    <class>org.apache.nifi.kerberos.KerberosProvider</class>
    <property name="Default Realm">NIFI.APACHE.ORG</property>
    <property name="Authentication Expiration">12 hours</property>
</provider>

将kerberos-provider具有以下特性：

物业名称	描述
`Authentication Expiration`	用户身份验证有效期的持续时间。如果用户从未注销，则需要在此持续时间之后重新登录。
`Default Realm`	当用户输入不完整的用户主体（即`NIFI.APACHE.ORG`）时提供的默认域。

另请参阅Kerberos服务以允许通过客户端Kerberos票证进行单点登录访问。

要使对nifi.properties和login-identity-providers.xml的更改生效，需要重新启动NiFi。如果NiFi是群集的，则所有节点上的配置文件必须相同。

OpenId Connect

要通过OpenId Connect启用身份验证，必须在nifi.properties中配置以下属性。

物业名称	描述
`nifi.security.user.oidc.preferred.jwsalgorithm`	用于验证身份令牌的首选算法。如果此值为空，则默认为`RS256`OpenId Connect Provider根据规范要求支持的值。如果这个值`HS256`，`HS384`或者`HS512`，NiFi将尝试验证HMAC使用指定的客户端机密保护令牌。如果此值为`none`，则NiFi将尝试验证不安全/普通令牌。此算法的其他值将尝试解析为RSA或EC算法，以与通过发现URL中找到的元数据中的jwks_uri提供的JSON Web Key（JWK）结合使用。
`nifi.security.user.oidc.discovery.url`	所需OpenId Connect Provider的发现URL （http://openid.net/specs/openid-connect-discovery-1_0.html）。
`nifi.security.user.oidc.connect.timeout`	与OpenId Connect Provider通信时连接超时。
`nifi.security.user.oidc.read.timeout`	与OpenId Connect Provider通信时读取超时。
`nifi.security.user.oidc.client.id`	注册OpenId Connect Provider后，NiFi的客户端ID。
`nifi.security.user.oidc.client.secret`	在向OpenId Connect Provider注册后，NiFi的客户机密。

Apache Knox

要通过Apache Knox启用身份验证，必须在nifi.properties中配置以下属性。

物业名称	描述
`nifi.security.user.knox.audiences`	可选的。逗号分隔列出的允许的受众群体。如果设置，则令牌中的受众必须出现在此列表中。可以在Knox中配置令牌中填充的受众。
`nifi.security.user.knox.url`	Apache Knox登录页面的URL。
`nifi.security.user.knox.publicKey`	Apache Knox公钥的路径，用于验证HTTP Cookie中的身份验证令牌的签名。
`nifi.security.user.knox.cookieName`	成功登录后Apache Knox将生成的HTTP Cookie的名称。

多租户授权

将NiFi配置为安全运行并使用身份验证机制后，您必须配置谁有权访问系统以及访问级别。您可以使用“多租户授权”执行此操作。多租户授权允许多组用户（租户）命令，控制和观察数据流的不同部分，具有不同级别的授权。当经过身份验证的用户尝试查看或修改NiFi资源时，系统会检查用户是否具有执行该操作的权限。这些权限由可以在系统范围内应用于单个组件的策略定义。

授权人配置

“授权者”通过在启动时创建初步授权，授予用户管理用户和策略的权限。

使用nifi.properties文件中的两个属性配置授权程序：

该nifi.authorizer.configuration.file属性指定定义授权器的配置文件。默认情况下，将选择位于根安装conf目录中的authorizers.xml文件。
该nifi.security.user.authorizer属性指示authorizers.xml文件中要使用的已配置授权者。

Authorizers.xml安装程序

该authorizers.xml文件用于定义和配置可用的授权人。默认授权程序是StandardManagedAuthorizer。托管授权程序由UserGroupProvider和AccessPolicyProvider组成。将加载用户，组和访问策略，并可通过这些提供程序进行配置。托管授权人将根据提供的用户，组和访问策略做出所有访问决策。

在启动期间，检查以确保没有两个具有相同身份/名称的用户/组。无论配置的实现如何，都会执行此检查。这是必要的，因为这是在访问决策期间识别和授权用户/组的方式。

FileUserGroupProvider

默认的UserGroupProvider是FileUserGroupProvider，但是，您可以将其他UserGroupProviders开发为扩展。FileUserGroupProvider具有以下属性：

用户文件 (Users File ) - FileUserGroupProvider存储用户和组的文件。默认情况下，users.xml文件的conf目录中选择。
旧版授权用户文件(Legacy Authorized Users File) - 现有authorized-users.xml的完整路径，该路径将自动用于将用户和组加载到用户文件中。
初始用户身份(Initial User Identity) - 用于为用户文件设定种子的用户和系统的标识。每个属性的名称必须是唯一的，例如：“初始用户身份A”，“初始用户身份B”，“初始用户身份C”或“初始用户身份1”，“初始用户身份2”，“初始用户身份3“

LdapUserGroupProvider

UserGroupProvider的另一个选项是LdapUserGroupProvider。默认情况下，此选项已注释掉，但可以配置为代替FileUserGroupProvider。这将从目录服务器同步用户和组，并以只读形式在NiFi UI中显示它们。

LdapUserGroupProvider具有以下属性：

物业名称	描述
`Group Member Attribute - Referenced User Attribute`	如果为空，则定义的属性值`Group Member Attribute`应为用户的完整dn。如果不为空，则此属性将定义用户ldap条目的属性，该属性定义的属性的值`Group Member Attribute`正在引用（即`uid`）。使用此属性还需要`User Search Base`配置。（即`member: cn=User 1,ou=users,o=nifi`vs. `memberUid: user1`）
`Authentication Strategy`	如何验证与LDAP服务器的连接。可能的值是`ANONYMOUS`，`SIMPLE`，`LDAPS`，或`START_TLS`。
`Manager DN`	用于绑定到LDAP服务器以搜索用户的管理器的DN。
`Manager Password`	用于绑定到LDAP服务器以搜索用户的管理器的密码。
`TLS - Keystore`	使用LDAPS或START_TLS连接到LDAP时使用的密钥库的路径。
`TLS - Keystore Password`	使用LDAPS或START_TLS连接到LDAP时使用的密钥库的密码。
`TLS - Keystore Type`	使用LDAPS或START_TLS（即`JKS`或`PKCS12`）连接到LDAP时使用的密钥库的类型。
`TLS - Truststore`	使用LDAPS或START_TLS连接到LDAP时使用的Truststore的路径。
`TLS - Truststore Password`	使用LDAPS或START_TLS连接到LDAP时使用的Truststore的密码。
`TLS - Truststore Type`	使用LDAPS或START_TLS（即`JKS`或`PKCS12`）连接到LDAP时使用的Truststore的类型。
`TLS - Client Auth`	使用LDAPS或START_TLS连接到LDAP时的客户端身份验证策略。可能的值是`REQUIRED`，`WANT`，`NONE`。
`TLS - Protocol`	使用LDAPS或START_TLS连接到LDAP时使用的协议。（即`TLS`，`TLSv1.1`，`TLSv1.2`，等等）。
`TLS - Shutdown Gracefully`	指定在关闭目标上下文之前是否应正常关闭TLS。默认为false。
`Referral Strategy`	处理推荐的策略。可能的值是`FOLLOW`，`IGNORE`，`THROW`。
`Connect Timeout`	连接超时的持续时间。（即`10 secs`）。
`Read Timeout`	读取超时的持续时间。（即`10 secs`）。
`Url`	以空格分隔的LDAP服务器的URL列表（即`ldap://<hostname>:<port>`）。
`Page Size`	检索用户和组时设置页面大小。如果未指定，则不执行分页。
`Sync Interval`	同步用户和组之间的持续时间。（即`30 mins`）。最低允许值是`10 secs`。
`User Search Base`	用于搜索用户的基本DN（即`ou=users,o=nifi`）。搜索用户时需要。
`User Object Class`	用于标识用户的对象类（即`person`）。搜索用户时需要。
`User Search Scope`	搜索范围进行搜索的用户（`ONE_LEVEL`，`OBJECT`，或`SUBTREE`）。搜索用户时需要。
`User Search Filter`	过滤用于搜索`User Search Base`（即`(memberof=cn=team1,ou=groups,o=nifi)`）的用户。可选的。
`User Identity Attribute`	用于提取用户身份的属性（即`cn`）。可选的。如果未设置，则使用整个DN。
`User Group Name Attribute`	用于定义组成员身份的属性（即`memberof`）。可选的。如果未设置，则不会通过用户计算组成员资格。将依赖于通过`Group Member Attribute`if set 定义的组成员身份。此属性的值是用户ldap条目中将属性与组关联的属性的名称。例如，该用户属性的值可以是dn或组名。在预期中配置了什么值`User Group Name Attribute - Referenced Group Attribute`。
`User Group Name Attribute - Referenced Group Attribute`	如果为空，则定义的属性值`User Group Name Attribute`应为该组的完整dn。如果不为空，则此属性将定义组ldap条目的属性，该属性定义的属性的值`User Group Name Attribute`正在引用（即`name`）。使用此属性还需要`Group Search Base`配置。
`Group Search Base`	用于搜索组的基本DN（即`ou=groups,o=nifi`）。搜索组时需要。
`Group Object Class`	用于标识组的对象类（即`groupOfNames`）。搜索组时必需。
`Group Search Scope`	搜索范围搜索组（`ONE_LEVEL`，`OBJECT`，或`SUBTREE`）。搜索组时必需。
`Group Search Filter`	过滤搜索群组`Group Search Base`。可选的。
`Group Name Attribute`	用于提取组名的属性（即`cn`）。可选的。如果未设置，则使用整个DN。
`Group Member Attribute`	用于定义组成员身份的属性（即`member`）。可选的。如果未设置，则不会通过组计算组成员身份。将依赖于通过`User Group Name Attribute`if set 定义的组成员身份。此属性的值是组ldap条目中的属性的名称，该属性将它们与用户相关联。例如，该组属性的值可以是dn或memberUid。在预期中配置了什么值`Group Member Attribute - Referenced User Attribute`。（即`member: cn=User 1,ou=users,o=nifi`vs. `memberUid: user1`）

nifi.properties中 指定的任何身份映射规则也将应用于用户身份。组名未映射。

复合实现

UserGroupProvider的另一个选项是复合实现。这意味着可以配置和组合多个源/实现。例如，管理员可以配置要从文件和目录服务器加载的用户/组。有两个复合实现，一个支持多个UserGroupProviders，一个支持多个UserGroupProviders和一个可配置的UserGroupProvider。

CompositeUserGroupProvider将支持从多个源检索用户和组。CompositeUserGroupProvider具有以下属性：

nifi.properties中指定的任何标识映射规则都不适用于此实现。基本实现需要应用此行为。

CompositeConfigurableUserGroupProvider将支持从多个源检索用户和组。此外，还需要一个可配置的用户组提供程序。可配置用户组提供程序中的用户是可配置的，但是从用户组提供程序[唯一键]之一加载的用户将不会。CompositeConfigurableUserGroupProvider具有以下属性：

物业名称描述

物业名称	描述
`User Group Provider` `[unique key]`	要加载的用户组提供程序的标识符。每个属性的名称必须是唯一的，例如：“用户组提供商A”，“用户组提供商B”，“用户组提供商C”或“用户组提供商1”，“用户组提供商2”，“用户组”提供者3“
`Configurable User Group Provider`	可配置的用户组提供程序。

User Group Provider

[unique key]

要加载的用户组提供程序的标识符。每个属性的名称必须是唯一的，例如：“用户组提供商A”，“用户组提供商B”，“用户组提供商C”或“用户组提供商1”，“用户组提供商2”，“用户组”提供者3“

Configurable User Group Provider

可配置的用户组提供程序。

FileAccessPolicyProvider

默认的AccessPolicyProvider是FileAccessPolicyProvider，但是，您可以将其他AccessPolicyProvider开发为扩展。FileAccessPolicyProvider具有以下属性：

物业名称	描述
`Node Group`	包含NiFi群集节点的组的名称。这种情况的典型用途是在群集中动态添加/删除节点。
`User Group Provider`	上面定义的用户组提供程序的标识符，用于访问用于托管访问策略的用户和组。
`Authorizations File`	FileAccessPolicyProvider将存储策略的文件。
`Initial Admin Identity`	初始管理员用户的身份，该用户将被授予对UI的访问权限，并且能够创建其他用户，组和策略。使用证书或LDAP或Kerberos主体时，此属性的值可以是DN。仅在未定义其他策略时才使用此属性。如果指定了此属性，则无法指定旧版授权用户文件。
`Legacy Authorized Users File`	现有authorized-users.xml的完整路径，该路径将自动转换为新的授权模型。如果指定了此属性，则无法指定初始管理员标识，并且仅在未定义其他用户，组和策略时才使用此属性。
`Node Identity`	NiFi群集节点的标识。在群集时，应定义每个节点的属性，以便每个节点都知道每个其他节点。如果不是群集，则可以忽略这些属性。每个属性的名称必须是唯一的，例如对于三节点群集：“节点标识A”，“节点标识B”，“节点标识C”或“节点标识1”，“节点标识2”，“节点标识” 3"

在初始管理员标识，节点标识属性中配置的标识或在旧版授权用户文件中发现的标识必须在配置的用户组提供程序中可用。

必须在配置的用户组提供程序中找到旧用户文件中的所有用户。

nifi.properties中 指定的任何标识映射规则也将应用于节点标识，因此值应为未映射的标识（即来自证书的完整DN）。必须在配置的用户组提供程序中找到此标识。

StandardManagedAuthorizer

默认授权程序是StandardManagedAuthorizer，但是，您可以将其他授权程序开发为扩展程序。StandardManagedAuthorizer具有以下属性：

FileAuthorizer

FileAuthorizer已被上述更精细的StandardManagedAuthorizer方法所取代。但是，由于向后兼容性原因，它仍然可用。FileAuthorizer具有以下属性：

物业名称	描述
`Node Identity`	NiFi群集节点的标识。在群集时，应定义每个节点的属性，以便每个节点都知道每个其他节点。如果不是群集，则可以忽略这些属性。
`Authorizations File`	FileAuthorizer存储策略的文件。默认情况下，authorizations.xml在`conf`目录中选择。
`Users File`	FileAuthorizer存储用户和组的文件。默认情况下，users.xml文件的`conf`目录中选择。
`Initial Admin Identity`	被授予对UI的访问权限并且能够创建其他用户，组和策略的初始管理员用户的身份。仅在未定义其他用户，组和策略时使用此属性。
`Legacy Authorized Users File`	现有authorized-users.xml的完整路径，该路径自动转换为多租户授权模型。仅在未定义其他用户，组和策略时使用此属性。

nifi.properties中 指定的任何标识映射规则也将应用于初始管理标识，因此该值应为未映射的标识。

nifi.properties中 指定的任何标识映射规则也将应用于节点标识，因此值应为未映射的标识（即来自证书的完整DN）。

初始管理员身份（新NiFi实例）

如果您是第一次设置安全的NiFi实例，则必须在authorizers.xml文件中手动指定“初始管理员标识” 。此初始管理员用户被授予对UI的访问权限，并且可以创建其他用户，组和策略。此属性的值可以是DN（使用证书或LDAP时）或Kerberos主体。如果您是NiFi管理员，请将自己添加为“初始管理员身份”。

编辑并保存authorizers.xml文件后，重新启动NiFi。重新启动期间，“初始管理员标识”用户和管理策略将添加到users.xml和authorizations.xml文件中。一旦NiFi启动，“初始管理员身份”用户就可以访问UI并开始管理用户，组和策略。

对于全新的安全流，提供“初始管理员身份”使用户可以访问用户界面并管理用户，组和策略。但是，如果该用户想要开始修改流，他们需要为根进程组授予自己的策略。系统无法自动执行此操作，因为在新流中，根进程组的UUID在生成flow.xml.gz之前不是永久性的。如果NiFi实例是从现有flow.xml.gz或从不安全到安全的1.x实例的升级，则“初始管理员身份”用户将自动获得修改流的权限。

一些常见用例如下所述。

基于文件（LDAP身份验证）

以下是使用John Smith名称的LDAP条目示例：

<authorizers>
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./conf/users.xml</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Initial User Identity 1">cn=John Smith,ou=people,dc=example,dc=com</property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">file-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">cn=John Smith,ou=people,dc=example,dc=com</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Node Identity 1"></property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

基于文件（Kerberos身份验证）

以下是使用名称John Smith和realm的示例Kerberos条目NIFI.APACHE.ORG：

<authorizers>
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./conf/users.xml</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Initial User Identity 1">johnsmith@NIFI.APACHE.ORG</property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">file-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">johnsmith@NIFI.APACHE.ORG</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Node Identity 1"></property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

基于LDAP的用户/组引用用户DN

以下是从LDAP加载用户和组的示例。组成员资格将通过每个组的成员属性来驱动。授权仍将使用基于文件的访问策略：

dn: cn=User 1,ou=users,o=nifi
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 1
sn: User1
uid: user1

dn: cn=User 2,ou=users,o=nifi
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 2
sn: User2
uid: user2

dn: cn=admins,ou=groups,o=nifi
objectClass: groupOfNames
objectClass: top
cn: admins
member: cn=User 1,ou=users,o=nifi
member: cn=User 2,ou=users,o=nifi

<authorizers>
    <userGroupProvider>
        <identifier>ldap-user-group-provider</identifier>
        <class>org.apache.nifi.ldap.tenants.LdapUserGroupProvider</class>
        <property name="Authentication Strategy">ANONYMOUS</property>

        <property name="Manager DN"></property>
        <property name="Manager Password"></property>

        <property name="TLS - Keystore"></property>
        <property name="TLS - Keystore Password"></property>
        <property name="TLS - Keystore Type"></property>
        <property name="TLS - Truststore"></property>
        <property name="TLS - Truststore Password"></property>
        <property name="TLS - Truststore Type"></property>
        <property name="TLS - Client Auth"></property>
        <property name="TLS - Protocol"></property>
        <property name="TLS - Shutdown Gracefully"></property>

        <property name="Referral Strategy">FOLLOW</property>
        <property name="Connect Timeout">10 secs</property>
        <property name="Read Timeout">10 secs</property>

        <property name="Url">ldap://localhost:10389</property>
        <property name="Page Size"></property>
        <property name="Sync Interval">30 mins</property>

        <property name="User Search Base">ou=users,o=nifi</property>
        <property name="User Object Class">person</property>
        <property name="User Search Scope">ONE_LEVEL</property>
        <property name="User Search Filter"></property>
        <property name="User Identity Attribute">cn</property>
        <property name="User Group Name Attribute"></property>
        <property name="User Group Name Attribute - Referenced Group Attribute"></property>

        <property name="Group Search Base">ou=groups,o=nifi</property>
        <property name="Group Object Class">groupOfNames</property>
        <property name="Group Search Scope">ONE_LEVEL</property>
        <property name="Group Search Filter"></property>
        <property name="Group Name Attribute">cn</property>
        <property name="Group Member Attribute">member</property>
        <property name="Group Member Attribute - Referenced User Attribute"></property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">ldap-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">John Smith</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Node Identity 1"></property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

该Initial Admin Identity值将根据值从John Smith的条目中加载cn User Identity Attribute。

基于LDAP的用户/组引用用户属性

以下是从LDAP加载用户和组的示例。组成员资格将通过每个组的成员uid属性驱动。授权仍将使用基于文件的访问策略：

dn: uid=User 1,ou=Users,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user1
cn: User 1

dn: uid=User 2,ou=Users,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: user2
cn: User 2

dn: cn=Managers,ou=Groups,dc=local
objectClass: posixGroup
cn: Managers
memberUid: user1
memberUid: user2

<authorizers>
    <userGroupProvider>
        <identifier>ldap-user-group-provider</identifier>
        <class>org.apache.nifi.ldap.tenants.LdapUserGroupProvider</class>
        <property name="Authentication Strategy">ANONYMOUS</property>

        <property name="Manager DN"></property>
        <property name="Manager Password"></property>

        <property name="TLS - Keystore"></property>
        <property name="TLS - Keystore Password"></property>
        <property name="TLS - Keystore Type"></property>
        <property name="TLS - Truststore"></property>
        <property name="TLS - Truststore Password"></property>
        <property name="TLS - Truststore Type"></property>
        <property name="TLS - Client Auth"></property>
        <property name="TLS - Protocol"></property>
        <property name="TLS - Shutdown Gracefully"></property>

        <property name="Referral Strategy">FOLLOW</property>
        <property name="Connect Timeout">10 secs</property>
        <property name="Read Timeout">10 secs</property>

        <property name="Url">ldap://localhost:10389</property>
        <property name="Page Size"></property>
        <property name="Sync Interval">30 mins</property>

        <property name="User Search Base">ou=Users,dc=local</property>
        <property name="User Object Class">posixAccount</property>
        <property name="User Search Scope">ONE_LEVEL</property>
        <property name="User Search Filter"></property>
        <property name="User Identity Attribute">cn</property>
        <property name="User Group Name Attribute"></property>
        <property name="User Group Name Attribute - Referenced Group Attribute"></property>

        <property name="Group Search Base">ou=Groups,dc=local</property>
        <property name="Group Object Class">posixGroup</property>
        <property name="Group Search Scope">ONE_LEVEL</property>
        <property name="Group Search Filter"></property>
        <property name="Group Name Attribute">cn</property>
        <property name="Group Member Attribute">memberUid</property>
        <property name="Group Member Attribute - Referenced User Attribute">uid</property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">ldap-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">John Smith</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Node Identity 1"></property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

Composite - 基于文件和LDAP的用户/组

以下是从LDAP和本地文件加载用户和组的示例复合实现。组成员资格将通过每个组的成员属性来驱动。来自LDAP的用户将是只读的，而从文件加载的用户可以在UI中进行配置。

dn: cn=User 1,ou=users,o=nifi
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 1
sn: User1
uid: user1

dn: cn=User 2,ou=users,o=nifi
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: User 2
sn: User2
uid: user2

dn: cn=admins,ou=groups,o=nifi
objectClass: groupOfNames
objectClass: top
cn: admins
member: cn=User 1,ou=users,o=nifi
member: cn=User 2,ou=users,o=nifi

<authorizers>
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./conf/users.xml</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Initial User Identity 1">cn=nifi-node1,ou=servers,dc=example,dc=com</property>
        <property name="Initial User Identity 2">cn=nifi-node2,ou=servers,dc=example,dc=com</property>
    </userGroupProvider>
    <userGroupProvider>
        <identifier>ldap-user-group-provider</identifier>
        <class>org.apache.nifi.ldap.tenants.LdapUserGroupProvider</class>
        <property name="Authentication Strategy">ANONYMOUS</property>

        <property name="Manager DN"></property>
        <property name="Manager Password"></property>

        <property name="TLS - Keystore"></property>
        <property name="TLS - Keystore Password"></property>
        <property name="TLS - Keystore Type"></property>
        <property name="TLS - Truststore"></property>
        <property name="TLS - Truststore Password"></property>
        <property name="TLS - Truststore Type"></property>
        <property name="TLS - Client Auth"></property>
        <property name="TLS - Protocol"></property>
        <property name="TLS - Shutdown Gracefully"></property>

        <property name="Referral Strategy">FOLLOW</property>
        <property name="Connect Timeout">10 secs</property>
        <property name="Read Timeout">10 secs</property>

        <property name="Url">ldap://localhost:10389</property>
        <property name="Page Size"></property>
        <property name="Sync Interval">30 mins</property>

        <property name="User Search Base">ou=users,o=nifi</property>
        <property name="User Object Class">person</property>
        <property name="User Search Scope">ONE_LEVEL</property>
        <property name="User Search Filter"></property>
        <property name="User Identity Attribute">cn</property>
        <property name="User Group Name Attribute"></property>
        <property name="User Group Name Attribute - Referenced Group Attribute"></property>

        <property name="Group Search Base">ou=groups,o=nifi</property>
        <property name="Group Object Class">groupOfNames</property>
        <property name="Group Search Scope">ONE_LEVEL</property>
        <property name="Group Search Filter"></property>
        <property name="Group Name Attribute">cn</property>
        <property name="Group Member Attribute">member</property>
        <property name="Group Member Attribute - Referenced User Attribute"></property>
    </userGroupProvider>
    <userGroupProvider>
        <identifier>composite-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.CompositeConfigurableUserGroupProvider</class>
        <property name="Configurable User Group Provider">file-user-group-provider</property>
        <property name="User Group Provider 1">ldap-user-group-provider</property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">composite-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">John Smith</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Node Identity 1">cn=nifi-node1,ou=servers,dc=example,dc=com</property>
        <property name="Node Identity 2">cn=nifi-node2,ou=servers,dc=example,dc=com</property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

在此示例中，用户和组是从LDAP加载的，但服务器是在本地文件中管理的。该Initial Admin Identity值来自基于的LDAP条目中的属性User Identity Attribute。该Node Identity值是建立使用本地文件Initial User Identity的属性。

旧版授权用户（NiFi实例升级）

如果要从0.x NiFi实例升级，则可以将先前配置的用户和角色转换为多租户授权模型。在authorizers.xml文件中，指定属性中现有authorized-users.xml文件的位置Legacy Authorized Users File。

这是一个示例条目：

<authorizers>
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./conf/users.xml</property>
        <property name="Legacy Authorized Users File">/Users/johnsmith/config_files/authorized-users.xml</property>

        <property name="Initial User Identity 1"></property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">file-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity"></property>
        <property name="Legacy Authorized Users File">/Users/johnsmith/config_files/authorized-users.xml</property>

        <property name="Node Identity 1"></property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

编辑并保存authorizers.xml文件后，重新启动NiFi。来自authorized-users.xml文件的用户和角色将转换并作为身份和策略添加到users.xml和authorizations.xml文件中。应用程序启动后，之前具有旧管理员角色的用户可以访问UI并开始管理用户，组和策略。

如果NiFi实例具有现有的flow.xml.gz，下表总结了分配给每个旧角色的全局和组件策略：

全球访问政策

	Admin	DFM	Monitor	Provenance	NiFi	Proxy
view the UI	*	*	*
access the controller - view	*	*	*		*
access the controller - modify		*
query provenance				*
access restricted components		*
access all policies - view	*
access all policies - modify	*
access users/user groups - view	*
access users/user groups - modify	*
retrieve site-to-site details					*
view system diagnostics		*	*
proxy user requests						*
access counters

根进程组上的组件访问策略

	Admin	DFM	Monitor	Provenance	Proxy
view the component	*	*	*
modify the component		*
view the data		*		*	*
modify the data		*			*
view provenance				*

有关表中各个策略的详细信息，请参阅访问策略。

如果属性Initial Admin Identity和Legacy Authorized Users File属性都存在值，则NiFi无法重新启动。您只能指定其中一个值来初始化授权。

不要手动编辑authorizations.xml文件。仅在初始设置期间以及之后使用NiFi UI创建授权。

群集节点标识

如果在群集环境中运行NiFi，则必须为每个节点指定标识。在启动期间创建节点通信所需的授权策略。

例如，如果要为每个节点设置具有以下DN的2节点群集：

cn=nifi-1,ou=people,dc=example,dc=com
cn=nifi-2,ou=people,dc=example,dc=com

<authorizers>
    <userGroupProvider>
        <identifier>file-user-group-provider</identifier>
        <class>org.apache.nifi.authorization.FileUserGroupProvider</class>
        <property name="Users File">./conf/users.xml</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Initial User Identity 1">johnsmith@NIFI.APACHE.ORG</property>
        <property name="Initial User Identity 2">cn=nifi-1,ou=people,dc=example,dc=com</property>
        <property name="Initial User Identity 3">cn=nifi-2,ou=people,dc=example,dc=com</property>
    </userGroupProvider>
    <accessPolicyProvider>
        <identifier>file-access-policy-provider</identifier>
        <class>org.apache.nifi.authorization.FileAccessPolicyProvider</class>
        <property name="User Group Provider">file-user-group-provider</property>
        <property name="Authorizations File">./conf/authorizations.xml</property>
        <property name="Initial Admin Identity">johnsmith@NIFI.APACHE.ORG</property>
        <property name="Legacy Authorized Users File"></property>

        <property name="Node Identity 1">cn=nifi-1,ou=people,dc=example,dc=com</property>
        <property name="Node Identity 2">cn=nifi-2,ou=people,dc=example,dc=com</property>
    </accessPolicyProvider>
    <authorizer>
        <identifier>managed-authorizer</identifier>
        <class>org.apache.nifi.authorization.StandardManagedAuthorizer</class>
        <property name="Access Policy Provider">file-access-policy-provider</property>
    </authorizer>
</authorizers>

在群集中，所有节点必须具有相同的authorizations.xml和users.xml。唯一的例外是，如果节点在加入群集之前具有空authorizations.xml和user.xml文件。在此方案中，节点在启动期间从群集继承它们。

现在已经创建了初始授权，可以在NiFi UI中创建和管理其他用户，组和授权。

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...