Hadoop KMS_Hadoop 中文网

Hadoop 文档

General

Common

HDFS

MapReduce

MapReduce REST APIs

YARN

YARN REST APIs

YARN Service

Submarine

Hadoop Compatible File Systems

Auth

Tools

Reference

Configuration

KMS客户端配置
知识管理系统

Hadoop KMS是基于Hadoop的KeyProvider API 的加密密钥管理服务器。

它提供了客户端和服务器组件，它们使用REST API通过HTTP进行通信。

客户端是KeyProvider实施，它使用KMS HTTP REST API与KMS进行交互。

KMS及其客户端具有内置的安全性，并且它们支持HTTP SPNEGO Kerberos身份验证和HTTPS安全传输。

KMS是Java Jetty Web应用程序。

KMS客户端配置

KMS客户端KeyProvider使用kms方案，并且嵌入式URL必须是KMS的URL。例如，对于在http：// localhost：9600 / kms上运行的KMS ，KeyProvider URI为kms：// http @ localhost：9600 / kms。而且，对于在https：// localhost：9600 / kms上运行的KMS ，KeyProvider URI为kms：// https @ localhost：9600 / kms

以下是在core-site.xml中将HDFS NameNode配置为KMS客户端的示例：

<属性>
  <name> hadoop.security.key.provider.path </ name>
  <value> kms：// http @ localhost：9600 / kms </ value>
  <说明>
    与使用的加密密钥进行交互时使用的KeyProvider
    在读写加密区域时。
  </ description>
</ property>

知识管理系统

启动/停止KMS

要启动/停止KMS，请使用hadoop --daemon start | stop kms。例如：

hadoop-3.2.1 $ hadoop --daemon启动kms

注：不建议使用kms.sh脚本。现在，它只是hadoop kms的包装。

KMS配置

在etc / hadoop / kms-site.xml配置文件中配置KMS支持的KeyProvider属性：

  <属性>
     <name> hadoop.kms.key.provider.uri </ name>
     <value> jceks：// file @ / $ {user.home} /kms.keystore </ value>
  </ property>

  <属性>
    <name> hadoop.security.keystore.java-keystore-provider.password-file </ name>
    <value> kms.keystore.password </ value>
  </ property>

通过类路径在Hadoop的配置目录中查找密码文件。

注意：您需要重新启动KMS才能使配置更改生效。

注意：KMS服务器可以选择任何KeyProvider实现作为支持提供者。此处的示例使用JavaKeyStoreProvider，该JavaKeyStoreProvider仅应用于实验目的，决不能在生产中使用。有关JavaKeyStoreProvider的详细用法和注意事项，请参阅Credential Provider API的“ Keystore Passwords”部分。

KMS HTTP配置

KMS将HTTP端口预先配置为9600。

KMS 在etc / hadoop / kms-site.xml中支持以下HTTP 配置属性。

注意：您需要重新启动KMS才能使配置更改生效。

KMS缓存

KMS具有两种缓存：用于缓存加密密钥的CachingKeyProvider和用于缓存EEK的KeyProvider。

CachingKeyProvider

KMS会在短时间内缓存加密密钥，以避免对基础KeyProvider的过多攻击。

默认情况下，此缓存处于启用状态（可以通过将hadoop.kms.cache.enable布尔属性设置为false 来禁用此缓存）

此缓存仅与以下3种方法一起使用：getCurrentKey（）和getKeyVersion（）以及getMetadata（）。

对于getCurrentKey（）方法，无论键被访问的次数是多少，高速缓存的条目最多保留30000毫秒（以避免将陈旧的键视为当前键）。

对于getKeyVersion（）和getMetadata（）方法，将保留缓存的条目，其默认不活动超时为600000毫秒（10分钟）。

当通过deleteKey（）删除键或调用invalidateCache（）时，缓存无效。

可以通过etc / hadoop / kms-site.xml配置文件中的以下属性来更改这些配置：

   <属性>
     <name> hadoop.kms.cache.enable </ name>
     <value> true </ value>
   </ property>

   <属性>
     <name> hadoop.kms.cache.timeout.ms </ name>
     <value> 600000 </ value>
   </ property>

   <属性>
     <name> hadoop.kms.current.key.cache.timeout.ms </ name>
     <value> 30000 </ value>
   </ property>

密钥提供者

在架构上，服务器端（例如KMS）和客户端（例如NameNode）都具有EEK的缓存。以下是可在缓存上配置的：

缓存的大小。这是每个密钥名称下可以缓存的最大EEK数。
缓存上的低水印。对于每个键名，如果在get调用之后，缓存的EEK的数量小于（大小*低水印），则将异步填充该键名下的缓存。对于每个键名，异步填充只能运行1个线程。
允许在缓存中填充队列的各个键名之间的整体异步线程的最大数量。
高速缓存的到期时间（以毫秒为单位）。内部使用Guava缓存作为缓存实现。到期方法是expireAfterAccess。

注意，由于异步填充机制，在rollNewVersion（）之后，调用者仍有可能获得旧的EEK。在最坏的情况下，调用者可能会达到（服务器端缓存大小+客户端缓存大小）旧EEK的数量，或者直到两个缓存都到期为止。为了避免锁定高速缓存，此行为是一种折衷方案，并且可以接受，因为旧版本的EEK仍可用于解密。

以下是配置及其默认值：

可以通过etc / hadoop / kms-site.xml配置文件中的以下属性来更改服务器端：

   <属性>
     <name> hadoop.security.kms.encrypted.key.cache.size </ name>
     <value> 500 </ value>
   </ property>

   <属性>
     <name> hadoop.security.kms.encrypted.key.cache.low.watermark </ name>
     <value> 0.3 </ value>
   </ property>

   <属性>
     <name> hadoop.security.kms.encrypted.key.cache.num.fill.threads </ name>
     <value> 2 </ value>
   </ property>

   <属性>
     <name> hadoop.security.kms.encrypted.key.cache.expiry </ name>
     <value> 43200000 </ value>
   </ property>

可以通过etc / hadoop / core-site.xml配置文件中的以下属性来更改客户端：

   <属性>
     <name> hadoop.security.kms.client.encrypted.key.cache.size </ name>
     <value> 500 </ value>
   </ property>

   <属性>
     <name> hadoop.security.kms.client.encrypted.key.cache.low-watermark </ name>
     <value> 0.3 </ value>
   </ property>

   <属性>
     <name> hadoop.security.kms.client.encrypted.key.cache.num.refill.threads </ name>
     <value> 2 </ value>
   </ property>

   <属性>
     <name> hadoop.security.kms.client.encrypted.key.cache.expiry </ name>
     <value> 43200000 </ value>
   </ property>

KMS汇总审核日志

汇总了审核日志，以供API访问GET_KEY_VERSION，GET_CURRENT_KEY，DECRYPT_EEK，GENERATE_EEK，REENCRYPT_EEK操作。

条目按（用户，键，操作）组合键分组为一个可配置的聚合间隔，此后，用户对给定键的用户对指定端点的访问次数将刷新到审核日志中。

聚合间隔是通过属性配置的：

  <属性>
    <name> hadoop.kms.aggregation.delay.ms </ name>
    <value> 10000 </ value>
  </ property>

KMS安全配置

启用Kerberos HTTP SPNEGO身份验证

使用KDC服务器的信息配置Kerberos etc / krb5.conf文件。

为KMS创建服务主体及其密钥表，它必须是HTTP服务主体。

使用正确的安全性值配置KMS etc / hadoop / kms-site.xml，例如：

   <属性>
     <name> hadoop.kms.authentication.type </ name>
     <value> kerberos </ value>
   </ property>

   <属性>
     <name> hadoop.kms.authentication.kerberos.keytab </ name>
     <value> $ {user.home} /kms.keytab </ value>
   </ property>

   <属性>
     <name> hadoop.kms.authentication.kerberos.principal </ name>
     <value> HTTP / localhost </ value>
   </ property>

   <属性>
     <name> hadoop.kms.authentication.kerberos.name.rules </ name>
     <value> DEFAULT </ value>
   </ property>

注意：您需要重新启动KMS才能使配置更改生效。

KMS Proxyuser配置

必须使用以下属性在etc / hadoop / kms-site.xml中配置每个proxyuser ：

  <属性>
    <name> hadoop.kms.proxyuser。＃USER＃.users </ name>
    <value> * </ value>
  </ property>

  <属性>
    <name> hadoop.kms.proxyuser。＃USER＃.groups </ name>
    <value> * </ value>
  </ property>

  <属性>
    <name> hadoop.kms.proxyuser。＃USER＃.hosts </ name>
    <value> * </ value>
  </ property>

＃USER＃是要配置的代理用户的用户名。

该用户属性表示可以冒充用户。

该组属性指示组中的用户被冒充必须属于。

必须定义用户或组属性中的至少一个。如果同时指定了两者，则配置的proxyuser将可以模拟用户列表中的user和用户，以及属于组列表中任一组的用户。

该主机属性指示从主机PROXYUSER可以使模拟请求。

如果用户，组或主机带有*，则表示proxyuser对用户，组或主机没有限制。

HTTPS上的KMS（SSL）

在etc / hadoop / kms-site.xml中启用SSL ：

  <属性>
    <name> hadoop.kms.ssl.enabled </ name>
    <value> true </ value>
    <说明>
      是否启用SSL。默认值为false，即禁用。
    </ description>
  </ property>

使用适当的值配置etc / hadoop / ssl-server.xml，例如：

<属性>
  <name> ssl.server.keystore.location </ name>
  <value> $ {user.home} /。keystore </ value>
  <description>要使用的密钥库。必须指定。</ description>
</ property>

<属性>
  <name> ssl.server.keystore.password </ name>
  <value> </ value>
  <description>必须指定。</ description>
</ property>

<属性>
  <name> ssl.server.keystore.keypassword </ name>
  <value> </ value>
  <description>必须指定。</ description>
</ property>

SSL密码可以由凭据提供者保护。请参阅凭据提供程序API。

您需要为KMS创建SSL证书。作为kms Unix用户，使用Java keytool命令创建SSL证书：

$ keytool -genkey -alias jetty -keyalg RSA

交互式提示中将询问您一系列问题。它将创建密钥库文件，该文件将命名为.keystore并位于用户的主目录中。

您为“密钥库密码”输入的密码必须与配置目录中ssl-server.xml中设置的属性ssl.server.keystore.password的值匹配。

回答“您的名字和姓氏是什么？” （即“ CN”）必须是运行KMS的计算机的主机名。

注意：您需要重新启动KMS才能使配置更改生效。

注意：某些旧的SSL客户端可能使用KMS服务器不支持的弱密码。建议升级SSL客户端。

ACL（访问控制列表）

KMS支持ACL（访问控制列表）以进行细粒度的权限控制。

KMS中存在两个级别的ACL：KMS ACL和密钥ACL。KMS ACL在KMS操作级别控制访问，并且在Key ACL之前。特别是，只有在KMS ACL级别上授予许可时，才可以对关键ACL进行许可检查。

以下各节介绍了KMS ACL和密钥ACL的配置和用法。

KMS ACL

KMS ACL配置在KMS etc / hadoop / kms-acls.xml配置文件中定义。该文件在更改时被热重载。

KMS通过设置的ACL配置属性支持细粒度的访问控制以及kms操作的黑名单。

首先检查访问KMS的用户是否将其包含在所请求操作的访问控制列表中，然后在允许访问之前检查是否将其排除在黑名单中。

<配置>
  <属性>
    <name> hadoop.kms.acl.CREATE </ name>
    <value> * </ value>
    <说明>
          创建键操作的ACL。
          如果用户不在GET ACL中，则不返回密钥材料
          作为回应的一部分。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.CREATE </ name>
    <value> hdfs，foo </ value>
    <说明>
          创建密钥操作的黑名单。
          如果用户在黑名单中，则不会返回关键材料
          作为回应的一部分。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.DELETE </ name>
    <value> * </ value>
    <说明>
          删除键操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.DELETE </ name>
    <value> hdfs，foo </ value>
    <说明>
          删除键操作的黑名单。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.ROLLOVER </ name>
    <value> * </ value>
    <说明>
          滚动键操作的ACL。
          如果用户不在GET ACL中，则不返回密钥材料
          作为回应的一部分。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.ROLLOVER </ name>
    <value> hdfs，foo </ value>
    <说明>
          过渡键操作黑名单。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.GET </ name>
    <value> * </ value>
    <说明>
          用于get-key-version和get-current-key操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.GET </ name>
    <value> hdfs，foo </ value>
    <说明>
          用于get-key-version和get-current-key操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.GET_KEYS </ name>
    <value> * </ value>
    <说明>
         用于获取键操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.GET_KEYS </ name>
    <value> hdfs，foo </ value>
    <说明>
          获取键操作的黑名单。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.GET_METADATA </ name>
    <value> * </ value>
    <说明>
        用于get-key-metadata和get-keys-metadata操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.GET_METADATA </ name>
    <value> hdfs，foo </ value>
    <说明>
         get-key-metadata和get-keys-metadata操作的黑名单。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.SET_KEY_MATERIAL </ name>
    <value> * </ value>
    <说明>
            免费的ACL用于CREATE和ROLLOVER操作，以允许客户端
            在创建或滚动密钥时提供密钥材料。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.SET_KEY_MATERIAL </ name>
    <value> hdfs，foo </ value>
    <说明>
            CREATE和ROLLOVER操作的免费黑名单，以允许客户端
            在创建或滚动密钥时提供密钥材料。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.GENERATE_EEK </ name>
    <value> * </ value>
    <说明>
          generateEncryptedKey的ACL
          CryptoExtension操作
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.GENERATE_EEK </ name>
    <value> hdfs，foo </ value>
    <说明>
          generateEncryptedKey的黑名单
          CryptoExtension操作
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.acl.DECRYPT_EEK </ name>
    <value> * </ value>
    <说明>
          用于解密EncryptedKey的ACL
          CryptoExtension操作
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.blacklist.DECRYPT_EEK </ name>
    <value> hdfs，foo </ value>
    <说明>
          解密EncryptedKey的黑名单
          CryptoExtension操作
    </ description>
  </ property>
</ configuration>

关键ACL

KMS在密钥级别支持所有非读取操作的访问控制。所有密钥访问操作均分类为：

管理-createKey，deleteKey，rolloverNewVersion
GENERATE_EEK-generateEncryptedKey，reencryptEncryptedKey，reencryptEncryptedKeys，warmUpEncryptedKeys
DECRYPT_EEK-解密密钥
读取-getKeyVersion，getKeyVersions，getMetadata，getKeysMetadata，getCurrentKey
全部-以上全部

这些可以在KMS etc / hadoop / kms-acls.xml中定义，如下所示

对于尚未明确配置键访问的所有键，可以为操作类型的子集配置默认键访问控制。

还可以为操作类型的子集配置“白名单”键ACL。白名单密钥ACL除了显式或默认的每密钥ACL之外，还授予对该密钥的访问权限。也就是说，如果未显式设置每个键的ACL，则如果用户存在于默认的每个键ACL或白名单键ACL中，则将授予该用户访问权限。如果显式设置了每个键的ACL，则如果每个键的ACL或白名单键的ACL中存在用户，则将授予该用户访问权限。

如果没有为特定密钥配置ACL，并且没有配置默认ACL，并且没有为请求的操作配置白名单密钥ACL，则访问将被拒绝。

注意：默认和白名单密钥ACL不支持ALL操作限定符。

  <属性>
    <name> key.acl.testKey1.MANAGEMENT </ name>
    <value> * </ value>
    <说明>
      创建键，删除键和rolloverNewVersion操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> key.acl.testKey2.GENERATE_EEK </ name>
    <value> * </ value>
    <说明>
      用于generateEncryptedKey操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> key.acl.testKey3.DECRYPT_EEK </ name>
    <value> admink3 </ value>
    <说明>
      ACL，用于cryptoEncryptedKey操作。
    </ description>
  </ property>

  <属性>
    <name> key.acl.testKey4.READ </ name>
    <value> * </ value>
    <说明>
      getKeyVersion，getKeyVersions，getMetadata，getKeysMetadata，
      getCurrentKey操作
    </ description>
  </ property>

  <属性>
    <name> key.acl.testKey5.ALL </ name>
    <value> * </ value>
    <说明>
      所有操作的ACL。
    </ description>
  </ property>

  <属性>
    <name> whitelist.key.acl.MANAGEMENT </ name>
    <value> admin1 </ value>
    <说明>
      将所有密钥的管理操作的ACL列入白名单。
    </ description>
  </ property>

  <！-
  定义了“ testKey3”密钥ACL。由于“白名单”
  除了DECRYPT_EEK，还定义了密钥
  admink3，admin1也可以执行DECRYPT_EEK操作
  在“ testKey3”上
->
  <属性>
    <name> whitelist.key.acl.DECRYPT_EEK </ name>
    <value> admin1 </ value>
    <说明>
      所有密钥的DECRYPT_EEK操作的白名单ACL。
    </ description>
  </ property>

  <属性>
    <name> default.key.acl.MANAGEMENT </ name>
    <value> user1，user2 </ value>
    <说明>
      对于所有非密钥的管理操作的默认ACL
      明确定义。
    </ description>
  </ property>

  <属性>
    <name> default.key.acl.GENERATE_EEK </ name>
    <value> user1，user2 </ value>
    <说明>
      对于所有非GENERATE_EEK操作的默认ACL
      明确定义。
    </ description>
  </ property>

  <属性>
    <name> default.key.acl.DECRYPT_EEK </ name>
    <value> user1，user2 </ value>
    <说明>
      对于所有非DECRYPT_EEK操作的默认ACL
      明确定义。
    </ description>
  </ property>

  <属性>
    <name> default.key.acl.READ </ name>
    <value> user1，user2 </ value>
    <说明>
      对于所有非键的READ操作的默认ACL
      明确定义。
    </ description>
  </ property>

KMS委派令牌配置

KMS支持委派令牌，以从没有Kerberos凭据的进程向密钥提供者进行身份验证。

KMS委托令牌身份验证扩展了默认的Hadoop身份验证。与Hadoop身份验证相同，不得使用委派令牌身份验证来获取或更新KMS委派令牌。有关更多详细信息，请参见Hadoop Auth页面。

此外，可以使用以下属性配置KMS委派令牌秘密管理器：

  <属性>
    <name> hadoop.kms.authentication.delegation-token.update-interval.sec </ name>
    <value> 86400 </ value>
    <说明>
      主密钥旋转的频率，以秒为单位。默认值1天。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.authentication.delegation-token.max-lifetime.sec </ name>
    <value> 604800 </ value>
    <说明>
      授权令牌的最大生存期，以秒为单位。默认值7天。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.authentication.delegation-token.renew-interval.sec </ name>
    <value> 86400 </ value>
    <说明>
      委派令牌的续订间隔（以秒为单位）。默认值1天。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.authentication.delegation-token.removal-scan-interval.sec </ name>
    <value> 3600 </ value>
    <说明>
      扫描间隔以删除过期的委托令牌。
    </ description>
  </ property>

高可用性

可以使用多个KMS实例来提供高可用性和可伸缩性。当前，有两种方法可以支持多个KMS实例：在负载均衡器/ VIP后面运行KMS实例，或使用LoadBalancingKMSClientProvider。

在这两种方法中，都必须对KMS实例进行特殊配置以使其可以作为单个逻辑服务正常运行，因为来自同一客户端的请求可能由不同的KMS实例处理。特别是，Kerberos委托人配置，HTTP身份验证签名和委托令牌需要特别注意。

负载均衡器或VIP的背后

因为KMS客户端和服务器通过HTTP上的REST API进行通信，所以可以使用负载均衡器或VIP分配传入流量，以实现可伸缩性和HA。在这种模式下，客户端不知道服务器端有多个KMS实例。

使用LoadBalancingKMSClientProvider

在负载均衡器或VIP后面运行多个KMS实例的替代方法是使用LoadBalancingKMSClientProvider。使用这种方法，KMS客户端（例如，HDFS NameNode）可以识别多个KMS实例，并以循环方式向它们发送请求。当hadoop.security.key.provider.path中指定了多个URI时，将隐式使用LoadBalancingKMSClientProvider 。

core-site.xml中的以下示例配置两个KMS实例kms01.example.com和kms02.example.com。主机名用分号分隔，所有KMS实例必须在同一端口上运行。

<属性>
  <name> hadoop.security.key.provider.path </ name>
  <value> kms：// https：//kms01.example.com; kms02.example.com：9600 / kms </ value>
  <说明>
    与使用的加密密钥进行交互时使用的KeyProvider
    在读写加密区域时。
  </ description>
</ property>

如果对KMS实例的请求失败，则客户端将重试下一个实例。仅当所有实例失败时，该请求才作为失败返回。

HTTP Kerberos主体配置

当KMS实例位于负载均衡器或VIP后面时，客户端将使用VIP的主机名。对于Kerberos SPNEGO身份验证，URL的主机名用于构造服务器的Kerberos服务名HTTP /＃HOSTNAME＃。这意味着所有KMS实例必须具有带有负载均衡器或VIP主机名的Kerberos服务名称。

为了能够直接访问特定的KMS实例，KMS实例还必须具有其自己的主机名的Keberos服务名。这是监视和管理目的所必需的。

Kerberos服务主体凭据（用于负载均衡器/ VIP主机名和实际KMS实例主机名）都必须位于配置用于身份验证的keytab文件中。并且配置中指定的主体名称必须为“ *”。例如：

  <属性>
    <name> hadoop.kms.authentication.kerberos.principal </ name>
    <value> * </ value>
  </ property>

注意：如果使用HTTPS，则必须将KMS实例使用的SSL证书配置为支持多个主机名（有关如何执行此操作的详细信息，请参阅Java 7 keytool SAN扩展支持）。

HTTP身份验证签名

KMS使用Hadoop身份验证进行HTTP身份验证。客户端成功通过身份验证后，Hadoop身份验证将发布一个已签名的HTTP Cookie。这个HTTP Cookie具有一个到期时间，在此之后它将触发一个新的身份验证序列。这样做是为了避免在客户端的每个HTTP请求上触发身份验证。

KMS实例必须验证其他KMS实例签名的HTTP Cookie签名。为此，所有KMS实例必须共享签名秘密。有关详细说明和配置示例，请参阅SignerSecretProvider配置。请注意，KMS配置必须以hadoop.kms.authentication为前缀，如以下示例所示。

可以使用在KMS中配置的Zookeeper服务（在kms-site.xml中具有以下属性）来完成此秘密共享：

  <属性>
    <name> hadoop.kms.authentication.signer.secret.provider </ name>
    <value> zookeeper </ value>
    <说明>
      指示签署身份验证cookie的机密如何
      存储。选项为“随机”（默认），“文件”和“ zookeeper”。
      如果将设置与多个KMS实例一起使用，则应使用“ zookeeper”。
      如果使用文件，则应配置signature.secret.file并指向机密文件。
    </ description>
  </ property>
  <属性>
    <name> hadoop.kms.authentication.signer.secret.provider.zookeeper.path </ name>
    <value> / hadoop-kms / hadoop-auth-signature-secret </ value>
    <说明>
      KMS实例将在其中存储和检索的Zookeeper ZNode路径
      的秘密。所有需要协调的KMS实例都应指向同一路径。
    </ description>
  </ property>
  <属性>
    <name> hadoop.kms.authentication.signer.secret.provider.zookeeper.connection.string </ name>
    <value> #HOSTNAME＃：＃PORT＃，... </ value>
    <说明>
      Zookeeper连接字符串，主机名和端口逗号列表
      分开。
    </ description>
  </ property>
  <属性>
    <name> hadoop.kms.authentication.signer.secret.provider.zookeeper.auth.type </ name>
    <value> sasl </ value>
    <说明>
      Zookeeper身份验证类型，“无”（默认）或“ sasl”（Kerberos）。
    </ description>
  </ property>
  <属性>
    <name> hadoop.kms.authentication.signer.secret.provider.zookeeper.kerberos.keytab </ name>
    <value> /etc/hadoop/conf/kms.keytab </ value>
    <说明>
      Kerberos密钥表的凭据的绝对路径
      连接到Zookeeper。
    </ description>
  </ property>
  <属性>
    <name> hadoop.kms.authentication.signer.secret.provider.zookeeper.kerberos.principal </ name>
    <value> kms /＃HOSTNAME＃</ value>
    <说明>
      用于连接到Zookeeper的Kerberos服务主体。
    </ description>
  </ property>

委托令牌

与HTTP身份验证类似，KMS也使用Hadoop身份验证作为委托令牌。

在HA下，一个KMS实例必须通过检查用于签署委托令牌的共享机密来验证另一个KMS实例给出的委托令牌。为此，所有KMS实例必须能够从ZooKeeper检索共享机密。

请参阅“ HTTP身份验证”部分中给出的示例，以配置ZooKeeper进行秘密共享。

KMS HTTP REST API

建立金钥

请求：

POST http：// HOST：PORT / kms / v1 / keys
内容类型：application / json

{
  “ name”：“ <键名>”，
  “ cipher”：“ <cipher>”，
  “ length”：<length>，// int
  “ material”：“ <material>”，// base64
  “ description”：“ <description>”
}

响应：

创建201
位置：http：// HOST：PORT / kms / v1 / key / <key-name>
内容类型：application / json

{
  “ name”：“ versionName”，
  “ material”：“ <material>”，// base64，没有GET ACL就不存在
}

滚动键

请求：

POST http：// HOST：PORT / kms / v1 / key / <key-name>
内容类型：application / json

{
  “ material”：“ <material>”，
}

响应：

200 OK
内容类型：application / json

{
  “ name”：“ versionName”，
  “ material”：“ <material>”，// base64，没有GET ACL就不存在
}

使密钥的缓存无效

请求：

POST http：// HOST：PORT / kms / v1 / key / <key-name> / _invalidatecache

响应：

200 OK

删除金钥

请求：

删除http：// HOST：PORT / kms / v1 / key / <key-name>

响应：

200 OK

获取关键元数据

请求：

获取http：// HOST：PORT / kms / v1 / key / <key-name> / _metadata

响应：

200 OK
内容类型：application / json

{
  “ name”：“ <键名>”，
  “ cipher”：“ <cipher>”，
  “ length”：<length>，// int
  “ description”：“ <description>”，
  “ created”：<millis-epoc>，//长
  “ versions”：<versions> // int
}

获取当前密钥

请求：

获取http：// HOST：PORT / kms / v1 / key / <key-name> / _currentversion

响应：

200 OK
内容类型：application / json

{
  “ name”：“ versionName”，
  “ material”：“ <material>”，// base64
}

生成当前KeyVersion的加密密钥

请求：

获取http：// HOST：PORT / kms / v1 / key / <密钥名称> / _ eek？eek_op = generate＆num_keys = <要生成的密钥数目>

响应：

200 OK
内容类型：application / json
[
  {
    “ versionName”：“ <encryptionVersionName>”，
    “ iv”：“ <iv>”，// base64
    “ encryptedKeyVersion”：{
        “ versionName”：“ EEK”，
        “ material”：“ <material>”，// base64
    }
  }，
  {
    “ versionName”：“ <encryptionVersionName>”，
    “ iv”：“ <iv>”，// base64
    “ encryptedKeyVersion”：{
        “ versionName”：“ EEK”，
        “ material”：“ <material>”，// base64
    }
  }，
  ...
]

解密加密密钥

请求：

POST http：// HOST：PORT / kms / v1 / keyversion / <版本名称> / _ eek？eek_op = decrypt
内容类型：application / json

{
  “ name”：“ <键名>”，
  “ iv”：“ <iv>”，// base64
  “ material”：“ <material>”，// base64
}

响应：

200 OK
内容类型：application / json

{
  “名称”：“ EK”，
  “ material”：“ <material>”，// base64
}

使用最新的KeyVersion重新加密加密的密钥

此命令采用以前生成的加密密钥，并使用KeyProvider中的最新KeyVersion加密密钥对其进行重新加密。如果最新的KeyVersion与用于生成加密密钥的密钥相同，则返回相同的加密密钥。

这通常在滚动加密密钥后很有用。重新加密已加密的密钥将允许使用最新版本的加密密钥对其进行加密，但仍使用相同的密钥材料和初始化向量。

请求：

POST http：// HOST：PORT / kms / v1 / keyversion / <版本名称> / _ eek？eek_op =重新加密
内容类型：application / json

{
  “ name”：“ <键名>”，
  “ iv”：“ <iv>”，// base64
  “ material”：“ <material>”，// base64
}

响应：

200 OK
内容类型：application / json

{
  “ versionName”：“ <encryptionVersionName>”，
  “ iv”：“ <iv>”，// base64
  “ encryptedKeyVersion”：{
      “ versionName”：“ EEK”，
      “ material”：“ <material>”，// base64
  }
}

使用最新的KeyVersion批量重新加密加密的密钥

上述重新加密密钥的批处理版本。此命令获取以前生成的加密密钥的列表，并使用KeyProvider中的最新KeyVersion加密密钥对其进行重新加密，然后以相同的顺序返回经过重新加密的加密密钥。对于每个加密密钥，如果最新的KeyVersion与用于生成加密密钥的密钥相同，则不执行任何操作，并返回相同的加密密钥。

这通常在滚动加密密钥后很有用。重新加密已加密的密钥将允许使用最新版本的加密密钥对其进行加密，但仍使用相同的密钥材料和初始化向量。

批处理请求的所有加密密钥都必须使用相同的加密密钥名称，但是可能使用不同版本的加密密钥。

请求：

POST http：// HOST：PORT / kms / v1 / key / <key-name> / _reencryptbatch
内容类型：application / json

[
  {
    “ versionName”：“ <encryptionVersionName>”，
    “ iv”：“ <iv>”，// base64
    “ encryptedKeyVersion”：{
        “ versionName”：“ EEK”，
        “ material”：“ <material>”，// base64
    }
  }，
  {
    “ versionName”：“ <encryptionVersionName>”，
    “ iv”：“ <iv>”，// base64
    “ encryptedKeyVersion”：{
        “ versionName”：“ EEK”，
        “ material”：“ <material>”，// base64
    }
  }，
  ...
]

响应：

200 OK
内容类型：application / json

[
  {
    “ versionName”：“ <encryptionVersionName>”，
    “ iv”：“ <iv>”，// base64
    “ encryptedKeyVersion”：{
        “ versionName”：“ EEK”，
        “ material”：“ <material>”，// base64
    }
  }，
  {
    “ versionName”：“ <encryptionVersionName>”，
    “ iv”：“ <iv>”，// base64
    “ encryptedKeyVersion”：{
        “ versionName”：“ EEK”，
        “ material”：“ <material>”，// base64
    }
  }，
  ...
]

获取密钥版本

请求：

获取http：// HOST：PORT / kms / v1 / keyversion / <版本名称>

响应：

200 OK
内容类型：application / json

{
  “ name”：“ versionName”，
  “ material”：“ <material>”，// base64
}

获取关键版本

请求：

获取http：// HOST：PORT / kms / v1 / key / <key-name> / _versions

响应：

200 OK
内容类型：application / json

[
  {
    “ name”：“ versionName”，
    “ material”：“ <material>”，// base64
  }，
  {
    “ name”：“ versionName”，
    “ material”：“ <material>”，// base64
  }，
  ...
]

获取密钥名称

请求：

获取http：// HOST：PORT / kms / v1 / keys / names

响应：

200 OK
内容类型：application / json

[
  “ <键名>”，
  “ <键名>”，
  ...
]

获取密钥元数据

获取http：// HOST：PORT / kms / v1 / keys / metadata？key = <key-name>＆key = <key-name>，...

响应：

200 OK
内容类型：application / json

[
  {
    “ name”：“ <键名>”，
    “ cipher”：“ <cipher>”，
    “ length”：<length>，// int
    “ description”：“ <description>”，
    “ created”：<millis-epoc>，//长
    “ versions”：<versions> // int
  }，
  {
    “ name”：“ <键名>”，
    “ cipher”：“ <cipher>”，
    “ length”：<length>，// int
    “ description”：“ <description>”，
    “ created”：<millis-epoc>，//长
    “ versions”：<versions> // int
  }，
  ...
]

弃用的环境变量

不推荐使用以下环境变量。而是设置相应的配置属性。

环境变量	配置属性	配置文件
KMS_TEMP	hadoop.http.temp.dir	kms-site.xml
KMS_HTTP_PORT	hadoop.kms.http.port	kms-site.xml
KMS_MAX_HTTP_HEADER_SIZE	hadoop.http.max.request.header.size和hadoop.http.max.response.header.size	kms-site.xml
KMS_MAX_THREADS	hadoop.http.max.threads	kms-site.xml
KMS_SSL_ENABLED	hadoop.kms.ssl.enabled	kms-site.xml
KMS_SSL_KEYSTORE_FILE	ssl.server.keystore.location	ssl-server.xml
KMS_SSL_KEYSTORE_PASS	ssl.server.keystore.password	ssl-server.xml

默认HTTP服务

名称	描述
/配置	显示配置属性
/ jmx	Java JMX管理界面
/ logLevel	获取或设置每个班级的日志级别
/日志	显示日志文件
/堆栈	显示JVM堆栈
/static/index.html	静态首页

要控制对servlet / conf，/ jmx，/ logLevel，/ logs和/ stacks的访问，请在kms-site.xml中配置以下属性：

  <属性>
    <name> hadoop.security.authorization </ name>
    <value> true </ value>
    <description>是否启用了服务级别授权？</ description>
  </ property>

  <属性>
    <name> hadoop.security.instrumentation.requires.admin </ name>
    <value> true </ value>
    <说明>
      指示是否需要管理员ACL才能访问
      工具Servlet（JMX，METRICS，CONF，STACKS）。
    </ description>
  </ property>

  <属性>
    <name> hadoop.kms.http.administrators </ name>
    <value> </ value>
    <description>用于管理员的ACL，此配置用于控制
      谁可以访问默认的KMS servlet。该值应为逗号
      用户和组的单独列表。用户列表排在第一位
      用空格和组列表隔开，
      例如“ user1，user2 group1，group2”。用户和组都是可选的，
      因此，“ user1”，“ group1”，“”，“ user1 group1”，“ user1，user2 group1，group2”
      都有效（请注意“ group1”中的前导空格）。'*'授予访问权限
      对于所有用户和组，例如'*'，'*'和'*'均有效。
    </ description>
  </ property>