DC/OS Apache Kafka 安全

DC/OS Apache Kafka 服务支持 Kafka的本地传输加密、身份认证和授权机制。该服务提供自动化和编排，以简化这些重要功能的使用。

有关这些功能的详细概述，请参阅此处，Kafka的安全文档可见此处。

注意：这些安全功能仅在 DC/OS Enterprise 1.10 及更高版本中可用。

传输加密

启用传输加密后，DC/OS Apache Kafka 将使用正确配置自动部署所有节点，以通过 SSL 加密通信。节点将使用 SSL 在它们之间安全地进行通信。

该服务使用 DC/OS CA 生成用于保护服务的 SSL 工件。任何信任 DC/OS CA 的客户端都会认为服务证书有效。

注意：对于 [身份认证](#authentication)，启用传输加密 *需要* 使用 [SSL 身份认证]，但是，对于 Kerberos 身份认证，则是可选的。

先决条件

DC/OS 服务帐户密钥存储在 DC/OS 密钥存储库中。
DC/OS 超级用户权限，用于修改服务帐户的权限。

配置传输加密

设置服务帐户

授予服务帐户正确的权限。

在 DC/OS 1.10，所需权限为 dcos:superuser full。
在 DC/OS 1.11+ 中，所需权限为：

dcos:secrets:default:/<service name>/* full
dcos:secrets:list:default:/<service name> read
dcos:adminrouter:ops:ca:rw full
dcos:adminrouter:ops:ca:ro full

其中 <service name> 是要安装的服务的名称。

安装服务

除了自有选项，安装 DC/OS Apache Kafka 服务包括以下选项：

{
    "service": {
        "service_account": "<your service account name>",
        "service_account_secret": "<full path of service secret>",
        "security": {
            "transport_encryption": {
                "enabled": true, "allow_plaintext": <true|false default false>

            }
        }
    }
}

可以更新运行中的 DC/OS Apache Kafka 服务，从而在初始安装后启用传输加密，但服务在过渡期间可能不可用。另外，您的 Kafka 客户端需要重新配置，除非 service.security.transport_encryption.allow_plaintext 被设置为 true。

验证传输加密已启用

服务部署完成后，为端点 broker-tls 检查 Kafka端点的列表。如果 service.security.transport_encryption.allow_plaintext 是 true，那么 broker 端点也可用。

客户端传输加密

启用传输加密时，服务客户端需要进行配置以使用 DC/OS CA 捆绑包以验证它们对服务所进行的连接。请查阅客户端的文档，了解信任 CA 并适当配置您的客户端的信息。

身份认证

DC/OS Apache Kafka 支持两个身份认证机制，即 SSL 和 Kerberos。两者受独立支持，不得组合。如果同时启用 SSL 和 Kerberos 身份认证，那么该服务将使用 Kerberos 身份认证。

注意： Kerberos 身份认证可以与传输加密结合使用。

Kerberos 身份认证

Kerberos 身份认证依赖中央权限来验证 Kafka 客户端（代理商、消费者或生产者）是他们所说的真实身份。DC/OS Apache Kafka 与现有 Kerberos 基础架构集成，以验证客户端的身份。

先决条件

从 DC/OS 集群可访问的 KDC 的主机名和端口
充分访问 KDC 的权限，以创建 Kerberos principal
充分访问 KDC 的权限，以检索已生成的 principal 的 keytab
DC/OS Enterprise CLI
DC/OS 超级用户权限

配置 Kerberos 身份认证

创建 principal

DC/OS Apache Kafka 服务要求部署每个代理的 Kerberos principal。每个 principal 必须为形式

<service primary>/kafka-<broker index>-broker.<service subdomain>.autoip.dcos.thisdcos.directory@<service realm>

带有：

service primary = service.security.kerberos.primary
broker index = 0 up to brokers.count - 1
service subdomain = service.name with all/'s removed
service realm = service.security.kerberos.realm

例如，如果使用以下选项安装：

{
    "service": {
        "name": "a/good/example",
        "security": {
            "kerberos": {
                "primary": "example",
                "realm": "EXAMPLE"
            }
        }
    },
    "brokers": {
        "count": 3
    }
}

则要创建的 principal 是：

example/kafka-0-broker.agoodexample.autoip.dcos.thisdcos.directory@EXAMPLE
example/kafka-1-broker.agoodexample.autoip.dcos.thisdcos.directory@EXAMPLE
example/kafka-2-broker.agoodexample.autoip.dcos.thisdcos.directory@EXAMPLE

活动目录

Microsoft Active Directory 可当作 Kerberos KDC 一样使用。这样做需要在 Active Directory 用户和 Kerberos principal 之间创建映射。

实用程序 ktpass 可用于从 Active Directory 创建 keytab 并同时生成映射。

然而，映射可以手动创建。对于一个 Kerberos principal，如 <primary>/<host>@<REALM>, Active Directory 用户应该拥有它 servicePrincipalName 和 `userPrincipalName”，属性设置为

servicePrincipalName = <primary>/<host>
userPrincipalName = <primary>/<host>@<REALM>

例如，存在 Kerberos principal example/kafka-0-broker.agoodexample.autoip.dcos.thisdcos.directory@EXAMPLE，则正确的映射应为，

servicePrincipalName = example&#x2F;kafka-0-broker.agoodexample.autoip.dcos.thisdcos.directory
userPrincipalName = example&#x2F;kafka-0-broker.agoodexample.autoip.dcos.thisdcos.directory@EXAMPLE

如果映射不正确或不存在，该服务将无法认证该 Principal。Kerberos 调试日志中的症状会是

KRBError:
sTime is Wed Feb 07 03:22:47 UTC 2018 1517973767000
suSec is 697984
error code is 6
error Message is Client not found in Kerberos database
sname is krbtgt/AD.MESOSPHERE.COM@AD.MESOSPHERE.COM
msgType is 30

在 userPrincipalName 设置不正确时的表单错误，以及

KRBError:
sTime is Wed Feb 07 03:44:57 UTC 2018 1517975097000
suSec is 128465
error code is 7
error Message is Server not found in Kerberos database
sname is kafka/kafka-1-broker.confluent-kafka.autoip.dcos.thisdcos.directory@AD.MESOSPHERE.COM
msgType is 30

在 servicePrincipalName 设置不正确时的表单错误。

在 DC/OS 密钥存储库中放置服务 Keytab

DC/OS Apache Kafka 服务使用包含所有节点 principal 的 keytab（服务 keytab）。创建上述 principal 后，生成服务 keytab ，确保包括所有节点 principal。这将作为秘钥存储在 DC/OS 密钥存储库中。

注意：DC/OS 1.10 不支持将二进制密钥直接添加到密钥存储库中，仅支持文本文件。而是，先进行文件的 base64 编码，并将其保存到密钥存储库中`/desired/path/__dcos_base64__secret_name`。DC/OS 安全模块将在服务使用文件时处理文件的解码。

服务 keytab 应存储在 service/path/name/service.keytab （如上文对 DC/OS 1.10 所备注，应为 __dcos_base64__service.keytab），在此service/path/name 将服务的路径和名称匹配。例如，如果使用这些选项安装

{
    "service": {
        "name": "a/good/example"
    }
}

则服务 keytab 应保存在 a/good/example/service.keytab。

向密钥存储库添加文件的文档可以参见此处。

注意密钥访问由 DC/OS Spaces控制，其功能如命名空间。位于与服务相同 DC/OS 空间中的任何密钥由该服务访问。然而，匹配两个路径是最安全的选项。此外，密钥名称 `service.keytab` 是惯例，而非要求。

安装服务

除了您自己的选项外，安装 DC/OS Apache Kafka 服务还提供以下选项：

{
    "service": {
        "security": {
            "kerberos": {
                "enabled": true,
                "enabled_for_zookeeper": <true|false default false>,
                "kdc": {
                    "hostname": "<kdc host>",
                    "port": <kdc port>
                },
                "primary": "<service primary default kafka>",
                "realm": "<realm>",
                "keytab_secret": "<path to keytab secret>",
                "debug": <true|false default false>
            }
        }
    }
}

注意： 如果 service.kerberos.enabled_for_zookeeper 设置为 true，那么是其他设置 kafka.kafka_zookeeper_uri 必须经过配置，以指向以下 kerberized Apache ZooKeeper：

{
    "kafka": {
        "kafka_zookeeper_uri": <list of zookeeper hosts>
    }
}

DC/OS Apache ZooKeeper 服务（kafka-zookeeper 包）用于此目的并支持 Kerberos。

注意： 可以在初始安装后启用 Kerberos，但服务在过渡期间可能不可用。另外，您的 Kafka 客户端需要重新配置。

SSL 身份认证

SSL 身份认证要求所有客户端（代理商、生产者或者消费者）出示可以获取其身份的有效证书。DC/OS Apache Kafka 将 SSL 证书的 CN 作为给定客户端的 principal。例如，将从证书 CN=bob@example.com,OU=,O=Example,L=London,ST=London,C=GB 中提取 principal bob@example.com。

先决条件

完成上述传输加密部分

安装服务

除了您自己的选项外，安装 DC/OS Apache Kafka 服务还提供以下选项：

{
    "service": {
        "service_account": "<service-account>",
        "service_account_secret": "<secret path>",
        "security": {
            "transport_encryption": {
                "enabled": true
            },
            "ssl_authentication": {
                "enabled": true
            }
        }
    }
}

注意： 可以在初始安装后启用 SSL 身份认证，但服务在过渡期间可能不可用。另外，您的 Kafka 客户端需要重新配置。

认证客户端

要针对Apache KafkaDC/OS 认证客户端，您需要将其配置为使用 DC/OS CA 签发的证书。生成证书签名请求后，您可以通过调用 API <dcos-cluster>/ca/api/v2/sign. Using curl，将其发送到 DC/OS CA，请求类似于：

$ curl -X POST \
    -H "Authorization: token=$(dcos config show core.dcos_acs_token)" \
    <dcos-cluster>/ca/api/v2/sign \
    -d '{"certificate_request": "<json-encoded-value-of-request.csr>"}'

响应将包含已签名的公用证书。有关 DC/OS CA API 的完整详细信息，请参阅此处。

授权

DC/OS Apache Kafka 服务支持 Kafka的 ACL-based 授权系统。要使用 Kafka的 ACL，必须按如上所述启用 SSL 或 Kerberos 身份认证。

启用授权

先决条件

完成上述 SSL 或 Kerberos 身份认证。

安装服务

通过以下选项（您自己的选项除外）安装 DC/OS Apache Kafka 服务（请记住，SSL 身份认证或 Kerberos 必须启用）：

{
    "service": {
        "security": {
            "authorization": {
                "enabled": true,
                "super_users": "<list of super users>",
                "allow_everyone_if_no_acl_found": <true|false default false>
            }
        }
    }
}

service.security.authorization.super_users 应设置为一个半冒号分隔的 principal 列表，用作超级用户（所有权限）。列表格式为用户：<user1>；用户：<user2>；.... Using Kerberos authentication, the “user” value is the Kerberos primary, and for SSL authentication the “user” value is the 证书的 CN Kafka broker 自动被指定为超级用户。

注意： 可以在初始安装后启用身份认证，但服务在过渡期间可能不可用。此外，Kafka 如果客户端的 principal 没有被正确分配 ACL，则客户端可能会出现故障。过渡期间， service.security.authorization.allow_everyone_if_no_acl_found 可设置为 true，以防止客户端出现故障，直到其 ACL 被正确设置。过度期间之后， service.security.authorization.allow_everyone_if_no_acl_found 应反转为 false。

在集群外部安全暴露 DC/OS Apache Kafka。

传输加密和 Kerberos 均紧密耦合到 Kafka broker 的 DNS 主机。因此，在集群外部暴露安全的 Apache Kafka 服务需要额外设置。

Broker to Client 连接

要在集群外部暴露安全的 Apache Kafka 服务，任何连接到服务的客户端必须能够通过分配给 broker 的 IP 地址访问服务的所有 broker。此 IP 地址将是其中之一：虚拟网络上的 IP 地址或 broker 正在运行的代理的 IP 地址。

转发 DNS 和自定义域

每个 DC/OS 集群都有一个唯一的加密 ID，可用于将 DNS 查询转发到该集群。要在集群外部安全地暴露服务，外部客户端必须将上游解析器配置为将 DNS 查询转发到服务的 DC/OS 集群，如所述此处。

仅配置转发，DC/OS 集群内的 DNS 条目在 <task-domain>.autoip.dcos. <cryptographic-id>.dcos.directory. 如果配置DNS别名, 您可以使用自定义域. <task-domain>.cluster-1.acmeco.net处可解析。在任一情况下，DC/OS Apache Kafka 服务都需要通过额外的安全选项进行安装：

{
    "service": {
        "security": {
            "custom_domain": "<custom-domain>"
        }
    }
}

其中 <custom-domain> 是其中之一 autoip.dcos. <cryptographic-id>.dcos.directory 或您的组织特定域名 (cluster-1.acmeco.net)。

作为具体实例，使用 cluster-1.acmeco.net 的自定义域，broker 0 任务将拥有 kafka-0-broker 主机。<service-name>.cluster-1.acmeco.net处可解析。

Kerberos Principal 变更

单独传输加密不需要任何其他更改。端点发现将正常运行，只要按此处所述进行配置，客户端即可与自定义域安全连接。

但是，Kerberos 需要稍微不同的配置。如创建 Principal 中所注明的，服务的 Principal 基于服务的主机名。创建 Kerberos Principal 时，确保使用正确的域。

例如，如果使用以下设置进行安装：

{
    "service": {
        "name": "a/good/example",
        "security": {
            "custom_domain": "cluster-1.example.net",
            "kerberos": {
                "primary": "example",
                "realm": "EXAMPLE"
            }
        }
    },
    "brokers": {
        "count": 3
    }
}

则要创建的 principal 是：

example/kafka-0-broker.agoodexample.cluster-1.example.net@EXAMPLE
example/kafka-1-broker.agoodexample.cluster-1.example.net@EXAMPLE
example/kafka-2-broker.agoodexample.cluster-1.example.net@EXAMPLE

安全

保护您的服务

DC/OS Apache Kafka 安全

传输加密

先决条件

配置传输加密

设置服务帐户

安装服务

验证传输加密已启用

客户端传输加密

身份认证

Kerberos 身份认证

先决条件

配置 Kerberos 身份认证

创建 principal

活动目录

在 DC/OS 密钥存储库中放置服务 Keytab

安装服务

SSL 身份认证

先决条件

安装服务

认证客户端

授权

启用授权

先决条件

安装服务

在集群外部安全暴露 DC/OS Apache Kafka。

Broker to Client 连接

转发 DNS 和自定义域

Kerberos Principal 变更