966,690 三月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
在Apache Hadoop中使用Rhino项目进行数据加密－Steven Ross专访
在Apache Hadoop中使用Rhino项目进行数据加密－Steven Ross专访
日. 估计阅读时间:
不到一分钟
欲知区块链、VR、TensorFlow等潮流技术和框架，请锁定
Author Contacted
相关厂商内容
相关赞助商
QCon北京-18日，北京&国家会议中心，
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。【dbdao Hadoop 大数据学习】HDFS中的传输加密
(window.slotbydup=window.slotbydup || []).push({
id: '2611110',
container: s,
size: '240,200',
display: 'inlay-fix'
您当前位置： &
[ 所属分类
| 时间 2016 |
作者 红领巾 ]
HDFS 实现透明的，端到端的加密。一旦配置，从指定的HDFS读取和写入数据都会透明的进行加密和解密，不需要用户应用程序代码的变更。这个加密是端到端的，也就意味着数据只能被客户端加密和解密。HDFS从来不会存储或访问未加密的数据或者为加密的加密key。这满足了2个典型的加密要求：静态加密（意思是数据在永久存储上，例如磁盘）以及在传输加密（例如当数据在网络中传输时）。加密可以在传统的数据管理软件/硬件栈的不同层级中完成。选择一个给定的层进行加密，有不同的优缺点。()1.应用程序层加密。这是最安全和最灵活的方法。该应用程序最终控制什么被加密，并且可以准确的反映用户的需求。但是，写应用程序做这个比较困难。对于现有的那些不支持加密的应用程序这也不是个选项。2.数据库层面加密。在性质方面和应用程序层很相似。大多数数据库供应商提供某种形式的加密。然而，可能会有性能问题。例如，索引是不能被加密的。3.文件系统层面加密。这个选项提供了很高的性能，对应用程序透明，并且通常很容易部署。但是其无法模拟一些应用程序的策略。例如，多租户的应用程序可能想在基于最终用户的基础上进行加密。数据库可能想对存储在单一文件中的每个字段进行不同的加密设置。4.磁盘级别加密。很容易实施 并且有很高的性能。但是很死板。只能真正保护物理盗窃。HDFS层级加密适合在数据库级别和文件系统级别之间的栈进行加密。其有很多积极的效果。HDFS加密能够提供很好的性能，并且现有的hadoop应用程序可以在加密数据上透明的运行。当其进行策略决定时，HDFS也比传统的文件系统有更多的上下文。()HDFS级别加密也可以防止在文件系统和其之下的攻击（OS-level攻击）。操作系统和磁盘只用加密字节交互，因为数据已经被HDFS加密。3 使用场景数据加密被不同的政府，金融和管理体系所需要。例如，医疗产业有HIPAA法规，卡支付行业的PCI DSS法规和美国FISMA规定。具有透明加密内置到HDFS使得组织遵守这些法规更容易。加密也可以在应用层面进行，但是是整合到HDFS，现有的应用程序可以操作加密数据不需要任何变更。这种集成架构意味着更强的加密文件语义和更好的于其他HDFS功能协调。()4.1 概述透明加密，我们在HDFS中引入一个新的抽象概念：加密区。一个加密区是一个特殊的目录，其中内容将在写的时候被透明的加密，读的时候被透明的解密。当每个加密空间被创建的时候会被分配一个单独的加密空间key。每个加密空间中的文件都有其唯一的数据加密key（DEK）。DEKs永远不会被DHFS直接处理。想法，HDFS只处理被加密数据的加密key（EDKEK）。客户端解密一个EDEK，然后使用DEK来读取和写入数据，HDFS datanodes仅仅看到的是一个加密的字节流。一个新的集群服务被用来管理加密keys：hadoop key 管理服务（KMS）。在HDFS加密情况中，KMS执行3个基本工作：1.提供访问到存储的加密空间key2.生成新的被加密数据的加密key到namenode上存储()3.解密被HDFS客户端使用的被加密数据的加密keyKMS将会在下面进行更详细的描述4.2 在加密空间中访问数据当在加密空间中创建一个新文件时，NameNode询问 KMS来生成新的EDEK其被加密空间的key加密。这个EDEK作为文件的元数据一部分持久的存储在namenode上。当在一个加密空间读取一个文件时，namenode为客户端提供文件的EDEK和用来加密EDEK的加密空间key版本。然后客户端会要求KMS解密EDEK，其会调用检查客户端访问加密空间key版本的权限。假设均成功，客户端会使用EDK来解密文件的内容。以上的步骤在读取和写入路径自动地发生，通过与DFS客户端，NameNode和KMS交互。访问被加密的文件数据和元数据被普通HDFS文件系统权限控制。这意味着，如果HDFS是抵抗力弱的（例如，通过获得未授权的HDFS超级用户），恶意用户只能访问密文和加密 key。但是，由于访问加密空间keys 是由在KMS上单独配置的权限控制和key 存储的，这并不构成安全威胁。()4.3 KMS, KeyProvider, EDEKsKMS是一个代理，是HDFS后台进程和客户端支持key存储的接口。支持key存储和KMS实施的hadoop KeyProvider的API，查看KMS文档获取更多的信息。在KeyProvider API中，每个加密key有一个唯一的key 名称。因为key可以被循环，一个key可以有多个key版本，每个key版本有其自己的key material（在加密和解密过程中实际使用的秘密字节）。一个加密key可以被其key名称捕获，返回最新的key版本，或者通过指定key版本。KMS实现额外的功能，可以创建和解密EEKs。创建和解密KEES完全发生在KMS中。重要的是，客户端需要创建或解密一个EEK，从不处理EEK的加密key。为了创建一个新的EEK，这个KMS生成一个新的随机key，使用指定的key加密它，并且返回EEK给客户端。为了解密一个EEK，KMS检查用户访问加密key，使用其来解密EEL，并范文被解密的加密key。在HDFS加密情况中，EEKs是加密数据的加密key（EDEKS），DEK用其来加密和解密文件数据。通常情况下，key存储只被最终用户控制用来解密DEK。这就意味着EDEKS可以被HDFS安全的存储和出来，因为HDFS用户将无法访问未加密的加密key。()一个必要的前提是一个KMS的实例，以及一个支持KMS key存储。更多的信息参考KMS文档。一旦一个KMS被设置，并且NameNode和HDFS客户端被正确的配置，一个管理员可以使用hadoop key 和hdfs crypto命令行工具来创建加密key和设置新的加密空间。已经存在的数据可以通过使用工具例如distcp，拷贝其到新的加密空间来加密。5.1 配置集群KeyProviderdfs.encryption.key.provider.uri当读取和写入加密空间时，使用KeyProvider和加密key进行交互。()5.2 设置一个加密算法和编码器hadoop.security.crypto.codec.classes.EXAMPLECIPHERSUITE对于一个给定的密码前缀编码，对于一个给定的密码编解码器包含一个以逗号分隔的列表实现的类（例如：EXAMPLECIPHERSUITE）。第一个如果可用的话将实现，其他的回退。hadoop.security.crypto.codec.classes.aes.ctr.nopadding默认值：org.apache.hadoop.crypto.OpensslAesCtrCryptoCodec,org.apache.hadoop.crypto.JceAesCtrCryptoCodecAES/CTR/NoPadding逗号分隔的编码解码列表。第一个如果可用的话将实现，其他的回退。()hadoop.security.crypto.cipher.suite默认值：AES/CTR/NoPadding对于编码解码的套件hadoop.security.crypto.jce.provider默认：None在CryptoCodec中用的JCE提供者名称hadoop.security.crypto.buffer.size默认：8192被CryptoInputStream 和CryptoOutputStream.使用的缓存大小()5.3 命名空间配置dfs.namenode.list.encryption.zones.num.responses默认：100当列出加密空间是，在批处理中最大返回的空间数目。逐渐的在在这个批处理中获取到列表可以提升namenode的性能()6.crypto 命令行接口6.1 createZone用法：[-createZone -keyName &keyName& -path &path&]创建一个新的加密空间
Path创建的加密空间的路径。这个必须是空目录
Keyname被加密空间使用key的名称
6.2 listZones用法：[-listZones]列出所有加密空间，需要有超级用户权限()7使用的例子假设你运行的用户是正常用户或者HDFS超级用户。为需要的环境使用sudo()# As the normal user, create a new encryption keyhadoopkeycreatemyKey# As the super user, create a new empty directory and make it an encryption zonehadoopfs -mkdir /zonehdfscrypto -createZone -keyNamemyKey -path /zone# chown it to the normal userhadoopfs -chownmyuser:myuser /zone# As the normal user, put a file in, read it outhadoopfs -puthelloWorld /zonehadoopfs -cat /zone/helloWorld8. distcp 注意事项8.1 作为超级用户运行一个场景的使用场景是distcp用于备份和灾难恢复目的，在集群间复制数据。这通常是由集群管理员执行，HDFS超级用户。()在使用HDFS加密时，为了启用这个相同的工作流程，我们引入了一个新虚拟路径的前缀/.reserved/raw/，这个给超级用户直接访问在文件系统中底层的数据块。其允许超级用户distcp数据而不需要访问加密key，也避免了重新加密数据和解密的开销。这也意味着源和目标的数据将是完全一样的字节，如果数据被一个新EDEK解密将不正确。当使用/.reserved/raw/来distcp加密数据，重要的是使用-px标记保持拓展属性。这是因为加密文件的属性（例如EDEK），是通过拓展属性被暴露在/.reserved/raw/，并且必须能够保证解码文件。这就意味着如果distcp在加密空间root或之上开始，其将自动地在目标创建一个加密空间（如果其不存在）。但是，我们还是建议管理员首先在目标集群创建相同的加密区，以免潜在的问题。8.2 在被加密和被解密位置之间拷贝默认情况下，distcp 比较由文件提供的校验码，来验证数据是否被成功拷贝到目标端。当在被解密和加密位置之间进行拷贝时，文件系统的校验码将不匹配，因为底层的数据块是不同的。在这种情况下，指定-skipcrccheck和-update distcp标记来避免校验码验证。9.攻击防范9.1 硬件访问漏洞这些漏洞假设攻击者已经获得了从集群机硬盘驱动器的物理访问。例如，datanodes和namenodes
访问包含数据加密密钥的进程的swap文件。()
就其本身而言，并不是明文暴露的，其也需要访问加密块文件。这个可以通过禁止swap来减轻，使用加密的swap或者使用mlock来防止keys被swap出去。2.访问被加密的块文件就其本身来说，并不是明文暴露的，它还需要访问DEKs9.2 root 访问漏洞这些漏洞假设攻击者已经获得了集群机器的root shell访问，例如datanodes和namenodes。大多数漏洞不能再HDFS中解决，因为一个恶意的root用户可以访问那些拥有加密key和明文存储的进程在内存中的状态。对于这些漏洞，唯一的缓解技术是仔细的限制和监测root shell访问。1.访问被加密块文件就其本身而言，其并未明文，它还需要访问加密keys。()2.转储客户端进程内存来获得DEKs，代表的tokens，明文。不能缓解3.记录网络流量以嗅探加密keys和传输的加密数据本身不能在没有EDEK加密key的情况下读取明文。4.转储datanode进程内存来获得加密的数据块就本身而言，无DEK无法读取明文5.转储namenode进程内存来获得被加密数据加密keys就本身而言，在没有EDEK的加密key和加密块文件下不能读取明文9.3 HDFS管理漏洞这些漏洞假设攻击者入侵HDFS，但是没有root或HDFS 用户shell访问。()1.访问加密的块文件就本身而言，没有EDEK和EDEK加密key不能读取明文2.访问加密空间和被加密的文件元数据（包含被加密数据加密keys），通过捕获 image。就本身而言，没有EDEK加密key不能读取明文9.4 流氓用户漏洞一个流氓用户可以收集他们能够访问的文件keys，并用它们随后来解密这些加密的文件。当用户访问这些文件时，他们已经访问了这些内容。这可以通过周期性的滚动key来缓解。本文固定链接：/archives/hdfs-transparent-encryption.html原文地址：http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/TransparentEncryption.html
转载请注明本文标题：本站链接：
分享请点击：
1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责；
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性，不作出任何保证或承若；
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
CodeSecTeam微信公众号
宠辱不惊，闲看庭前花开花落；去留无意，慢随天外云卷云舒；
手机客户端11722人阅读
HDFS（61）
Hadoop（102）
之前写了许多关于数据迁移的文章,也衍生的介绍了很多HDFS中相关的工具和特性,比如,等等.但是今天本文所要讲的主题转移到了另外一个领域数据安全.数据安全一直是用户非常重视的一点,所以对于数据管理者,务必要做到以下原则:
数据不丢失,不损坏,数据内容不能被非法查阅.
本文所主要描述的方面就是上面原则中最后一点,保证数据不被非法查阅.在HDFS中,就有专门的功能来做这样的事情,Encryption zone,数据加密空间,
Encryption zone综述
HDFS Encryption zone加密空间是一种end-to-end(端到端)的加密模式.其中的加/解密过程对于客户端来说是完全透明的.数据在客户端读操作的时候被解密,当数据被客户端写的时候被加密,所以HDFS本身并不是一个主要的参与者,形象的说,在HDFS中,你看到的只是一堆加密的数据流.
Encryption zone原理介绍
了解HDFS数据加密空间的原理对我们使用Encryption zone有很大的帮助.Encryption zone是HDFS中的一个抽象概念,它表示在此空间的内容在写的时候会被透明的加密,同时在读的时候,被透明的解密.这就是核心所在.具体到细小的细节.
1.每个encryption zone 会与每个encryption zone key相关联,而这个key就是会在创建encryption zone的时候同时被指定.
2.每个encryption zone中的文件会有其唯一的data encryption key数据加密key,简称就是DEK.
3.DEK不会被HDFS直接处理,取而代之的是,HDFS只处理经过加密的DEK, 就是encrypted data encryption key,缩写就是EDEK.
4.客户端询问KMS服务去解密EDEK,然后利用解密后得到的DEK去读/写数据.
在第四步骤有一个很重要的过程:
在客户端向KMS服务请求时候,会有相关权限验证,不符合要求的客户端将不会得到解密好的DEK.而且KMS的权限验证是独立于HDFS的,是自身的一套权限验证.
下面是对应的原理展示图:
Key Provider可以理解为是一个key store的保存库,其中KMS是其中的一个实现.
Encryption zone源码实现
这个小节,我们将从源码的层面对上述原理做跟踪分析.这里可以分为2大方向,1个是创建文件,并且写文件数据;2.读文件数据内容.
Encryption zone下的写文件
首先客户端发起createFile请求,到了NameNode这边,会调用startFile方法,里面就会有DEK,EDEK的生成
private HdfsFileStatus startFileInt(final String src,
PermissionStatus permissions, String holder, String clientMachine,
EnumSet&CreateFlag& flag, boolean createParent, short replication,
long blockSize, CryptoProtocolVersion[] supportedVersions,
boolean logRetryCache)
throws IOException {
FSDirWriteFileOp.EncryptionKeyInfo ezInfo =
// 判断key provider是否为空
if (provider != null) {
readLock();
checkOperation(OperationCategory.READ);
// 不为空,就生成EncryptionKey info.
ezInfo = FSDirWriteFileOp
.getEncryptionKeyInfo(this, pc, src, supportedVersions);
} finally {
readUnlock();
// Generate EDEK if necessary while not holding the lock
if (ezInfo != null) {
// 然后根据ezInfo的key名称生成EDEK信息在ezInfo中
ezInfo.edek = FSDirEncryptionZoneOp
.generateEncryptedDataEncryptionKey(dir, ezInfo.ezKeyName);
EncryptionFaultInjector.getInstance().startFileAfterGenerateKey();
// 继续调用startFile方法
stat = FSDirWriteFileOp.startFile(this, pc, src, permissions, holder,
clientMachine, flag, createParent,
replication, blockSize, ezInfo,
toRemoveBlocks, logRetryCache);
继续方法的调用
static HdfsFileStatus startFile(
FSNamesystem fsn, FSPermissionChecker pc, String src,
PermissionStatus permissions, String holder, String clientMachine,
EnumSet&CreateFlag& flag, boolean createParent,
short replication, long blockSize,
EncryptionKeyInfo ezInfo, INode.BlocksMapUpdateInfo toRemoveBlocks,
boolean logRetryEntry)
throws IOException {
assert fsn.hasWriteLock();
CipherSuite suite = null;
CryptoProtocolVersion version = null;
KeyProviderCryptoExtension.EncryptedKeyVersion edek = null;
if (ezInfo != null) {
edek = ezInfo.
suite = ezInfo.
version = ezInfo.protocolV
FileEncryptionInfo feInfo = null;
final EncryptionZone zone = FSDirEncryptionZoneOp.getEZForPath(fsd, iip);
if (zone != null) {
if (suite == null || edek == null) {
throw new RetryStartFileException();
final String ezKeyName = zone.getKeyName();
if (!ezKeyName.equals(edek.getEncryptionKeyName())) {
throw new RetryStartFileException();
feInfo = new FileEncryptionInfo(suite, version,
edek.getEncryptedKeyVersion().getMaterial(),
edek.getEncryptedKeyIv(),
ezKeyName, edek.getEncryptionKeyVersionName());
OK,完成了这些操作之后,将会返回一个HDFSFileStatus对象,此对象将会被DFSOutputstream利用.下面就是客户端的解密DEDK,并加密数据的过程了.
public HdfsDataOutputStream createWrappedOutputStream(DFSOutputStream dfsos,
FileSystem.Statistics statistics, long startPos) throws IOException {
final FileEncryptionInfo feInfo = dfsos.getFileEncryptionInfo();
if (feInfo != null) {
getCryptoProtocolVersion(feInfo);
final CryptoCodec codec = getCryptoCodec(conf, feInfo);
KeyVersion decrypted = decryptEncryptedDataEncryptionKey(feInfo);
final CryptoOutputStream cryptoOut =
new CryptoOutputStream(dfsos, codec,
decrypted.getMaterial(), feInfo.getIV(), startPos);
return new HdfsDataOutputStream(cryptoOut, statistics, startPos);
return new HdfsDataOutputStream(dfsos, statistics, startPos);
我们可以继续完decryptEncryptedDataEncryptionKey方法,验证是否有向KeyProvider方法请求服务.
private KeyVersion decryptEncryptedDataEncryptionKey(FileEncryptionInfo
feInfo) throws IOException {
try (TraceScope ignored = tracer.newScope("decryptEDEK")) {
KeyProvider provider = getKeyProvider();
if (provider == null) {
throw new IOException("No KeyProvider is configured, cannot access" +
" an encrypted file");
EncryptedKeyVersion ekv = EncryptedKeyVersion.createForDecryption(
feInfo.getKeyName(), feInfo.getEzKeyVersionName(), feInfo.getIV(),
feInfo.getEncryptedDataEncryptionKey());
KeyProviderCryptoExtension cryptoProvider = KeyProviderCryptoExtension
.createKeyProviderCryptoExtension(provider);
return cryptoProvider.decryptEncryptedKey(ekv);
} catch (GeneralSecurityException e) {
throw new IOException(e);
构造完加密输出流对象之后CryptoOutputStream之后,在随后的写操作中,数据都会额外经过一步加密算法的操作.此部分的过程调用图如下:
Encryption zone下的读文件
读文件部分的操作与写文件非常类似.
首先是构造出目标文件的HDFSFileStatus对象,然后取出其中的FileEncryptionInfo,在此过程中FileEncryptionInfo会被设置到LocatedBlocks中.
private static HdfsLocatedFileStatus createLocatedFileStatus(
FSDirectory fsd, byte[] path, INodeAttributes nodeAttrs,
byte storagePolicy, int snapshot,
boolean isRawPath, INodesInPath iip) throws IOException {
// 然后设置到LocatedBlocks中
loc = fsd.getBlockManager().createLocatedBlocks(
fileNode.getBlocks(snapshot), fileSize, isUc, 0L, size, false,
inSnapshot, feInfo, ecPolicy);
然后这些Blocks信息会以参数的信息传入到DFSInputStream,并在方法fetchLocatedBlocksAndGetLastBlockLength被设置到变量中.
private long fetchLocatedBlocksAndGetLastBlockLength(boolean refresh)
throws IOException {
LocatedBlocks newInfo = locatedB
// 将locatedBlocks中的EncryptionInfo信息设置到变量中
fileEncryptionInfo = locatedBlocks.getFileEncryptionInfo();
return lastBlockBeingWrittenL
然后此信息同样会被取出用到加密输入流中
public HdfsDataInputStream createWrappedInputStream(DFSInputStream dfsis)
throws IOException {
final FileEncryptionInfo feInfo = dfsis.getFileEncryptionInfo();
if (feInfo != null) {
getCryptoProtocolVersion(feInfo);
final CryptoCodec codec = getCryptoCodec(conf, feInfo);
final KeyVersion decrypted = decryptEncryptedDataEncryptionKey(feInfo);
final CryptoInputStream cryptoIn =
new CryptoInputStream(dfsis, codec, decrypted.getMaterial(),
feInfo.getIV());
return new HdfsDataInputStream(cryptoIn);
return new HdfsDataInputStream(dfsis);
与之前的过程非常的类似,在加密输入流中,就会对读取的数据进行解密,使得用户能看到正常的数据.同样给出过程图:
Encryption zone的管理
在源码分析的最后部分,这里再简单描述一下HDFS的Encryption zone的中心管理.同样是一个叫做EncryptionZoneManager的类来专门做这个事情的,但是有一点不同,他保存的对象不是EncryptionZone,而是EncryptionZoneInt.
public class EncryptionZoneManager {
public static Logger LOG = LoggerFactory.getLogger(EncryptionZoneManager
// 用TreeMap保存的Encryption zone列表
private final TreeMap&Long, EncryptionZoneInt& encryptionZ
private final FSD
private final int maxListEncryptionZonesR
这里的TreeMap的key位置保存的encryption zone的对应目录的indeed.
EncryptionZoneInt与EncryptionZone有什么微妙的关系呢?
在具体使用的时候,EncryptionZoneInt会被用来构造EncryptionZone
EncryptionZone getEZINodeForPath(INodesInPath iip) {
final EncryptionZoneInt ezi = getEncryptionZoneForPath(iip);
if (ezi == null) {
return null;
return new EncryptionZone(ezi.getINodeId(), getFullPathName(ezi),
ezi.getSuite(), ezi.getVersion(), ezi.getKeyName());
通过判断目标路径是否在encryption zone列表中,来判断此文件是否为加密文件,以为inodeId作为key去map中取出.
下面给出Encryption zone管理的结构图:
Encryption zone的使用
最后再介绍以下Encryption zone功能的具体配置使用.总的来说,住需要完成几个相关的配置项即可.
第一步: 完成keyProveider的配置
将已存在的keyProvider的URL地址配置到下面的配置中
dfs.encryption.key.provider.uri
第二步: 加密算法相关的配置
主要有以下的一些配置
hadoop.security.crypto.codec.classes.EXAMPLECIPHERSUITE
hadoop.security.crypto.codec.classes.aes.ctr.nopadding
hadoop.security.crypto.cipher.suite
hadoop.security.crypto.jce.provider
hadoop.security.crypto.buffer.size
当然这些配置并不需要额外配置,采用默认配置也是可以的.
第三步: 配置listZone响应回复的个数
此配置会在listZones的命令中起到作用.
dfs.namenode.list.encryption.zones.num.responses
第四步: 创建Encryption zone加密空间
这里的加密空间是针对目录级别的,并且还需要设置一个key名称,使用的命令如下
hdfs crypto -createZone -keyName &keyName& -path &path&
这里的path是要已经建好的目录,此命令的作用相当于将目标目录作为一个加密空间,在此目录下的文件在读写的过程中,被加/解密.
以上操作完成之后,加密空间就基本创建好了,可以用listZones的命令查看当前已创建的加密空间
hdfs crypto -listZones
然后此目录文件数据的加解密过程对于客户端来说完全是透明的了.
Encryption zone使用范例
下面举出官方的使用例子
# 以普通用户的身份创建一个加密key
hadoop key create myKey
# 以超级用户的身份创建一个空目录,并使之成为加密空间
hadoop fs -mkdir /zone
hdfs crypto -createZone -keyName myKey -path /zone
# 修改此目录权限为普通用户的
hadoop fs -chown myuser:myuser /zone
# 以普通用户的身份进行put上传文件和cat查看文件操作
hadoop fs -put helloWorld /zone
hadoop fs -cat /zone/helloWorld
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：838832次
积分：8962
积分：8962
排名：第1739名
原创：246篇
评论：247条
Apache Hadoop Committer，其中主要研究HDFS。毕业于HDU计算机系，研究领域分布式计算，大数据，数据挖掘，机器学习，算法。曾就职于国内女性电商平台蘑菇街，目前就职于唯品会上海研发中心，数据平台与应用部门
文章：29篇
阅读：118904
阅读：9959
阅读：13213
文章：11篇
阅读：18407
文章：36篇
阅读：110737
(1)(1)(3)(5)(3)(3)(4)(7)(6)(3)(2)(5)(4)(4)(6)(6)(4)(5)(4)(6)(9)(6)(4)(5)(6)(10)(11)(23)(20)(26)(37)(5)(4)(1)