fabric区块链技术教程,fabric区块链技术原理示意图

  

  在本教程中,我们将学习如何配置和动态更新Hyperledger结构区块链的访问控制列表(ACL)。教程分为两部分:1 .了解并配置Hyperledger Fabric的访问控制列表;2.动态更新通道配置中的访问控制列表。我们将介绍fabric中默认ACL的内容和格式,并以通道管理员的角色管理通道ACL的配置。   

  

  相关教程:Fabric区块链Java开发详解| Node详解。织物区块链的JS开发   

  

  1.Hyperledger结构中访问控制列表/ACL的基本概念Hyperledger结构中有两种类型的访问控制策略:   

  

  签名策略:签名策略隐式元策略:隐式元策略签名策略通过检查请求中的签名来识别特定用户。例如:   

  

  policies : My Policy 3360 Type 3360 Signature Rule :“org 1 . peer或Org2.peer”签名策略支持的关键字包括:AND、OR和NOutOf,这些关键字可用于组合强大的访问控制规则,例如:   

  

  可以发布由组织A的管理员签名的请求,并且可以发布由20个组织中超过一半的管理员签名的请求。隐式元策略通过聚合子代签名策略来定义访问控制规则,支持“组织半数以上管理员签名的请求可以释放”等默认访问规则。隐式元策略的定义方法类似于签名策略,但略有不同。其形式如下:   

  

  ALL|ANY|MAJORITY sub_policy下面是一个隐式元策略的示例:   

  

  Policies :另一个Policy 3360 Type 3360隐式元规则3360' Majority Admins' 2、Hyperledger Fabric的默认访问控制列表默认访问控制规则在configtx.yaml中定义,由configtxgen用来生成通道配置。在官方提供的configtx.yaml示例中,第35行定义了签名策略,第194行定义了隐式元策略,第131行定义了访问控制列表/ACL。   

  

  3.自定义Hyperledger结构的访问控制列表。让我们编辑configtx.yaml中的Application: ACLs部分,以修改以下内容:   

  

  同行/提议者3360/渠道/应用/作者是:   

  

  peer/propose :/channel/application/MyPolicy,其中my policy定义如下:   

  

  策略:读者:类型:隐式元规则:“任何读者”写入者:类型:隐式元规则:“任何写入者”管理员:类型3360隐式元规则3360“主要管理员”我的策略3360类型3360签名规则3360”或(' org1msp。我的策略规定只有客户端角色可以执行相应的任务。   

  

  不要忘记生成和更新CA和管理员证书。   

  

  现在让我们尝试从Org1Client调用链代码:   

  

     

  

  现在使用Org2Client调用链代码:   

  

     

  

  可以清楚的看到,peer/propose不再接受ORG2的客户端的调用。   

  

  4.有两种方法可以通过动态更新Hyperledger结构通道的ACL配置来更新访问控制策略:   

  

  编辑configtx.yaml,只适用于新建立的通道。它直接更新特定通道中的ACL配置,并且适用于现有通道。在下文中,我们将展示如何更新现有通道中的访问控制列表配置。   

  

  在执行以下操作之前,请记住启动您的Hyperledger Fabric网络。   

  

  4.1访问命令行界面Hyperledger Fabric有一个自动创建的cli容器,可以提供操作节点的命令行界面。执行以下命令进入cli界面:   

  

  Docker exec -it cli bash然后设置程序需要使用的环境变量:   

  

  export CHANNEL _ NAME=mychannel export CORE _ PEER _ MSPCONFIGPATH=/opt/gopath/src/吉斯   

ub.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/mspexport CORE_PEER_ADDRESS=peer0.org1.example.com:7051export CORE_PEER_LOCALMSPID="Org1MSP"export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crtexport ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem4.2 获取指定Fabric通道的当前配置执行下面命令获取通道的当前配置并写入文件config_block.pb:

  

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA4.3 将通道配置转换为JSON格式config_block.pb是二进制编码的区块配置数据,我们要将其先转换为 容易查看、修改的JSON格式:

  

configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data<0>.payload.data.config > config.json4.4 创建通道配置的JSON副本以便修改后续的修改将在副本modified_config.json上进行:

  

cp config.json modified_config.json4.5 修改JSON副本的通道配置可以使用你喜欢的任何编辑器来修改JSON副本,比如用vim:

  

vim modified_config.json我们将MyPolicy的描述从Org1MSP修改为Org2MSP:

  

  

修改后记得保存。

  

4.6 将修改后的通道配置JSON副本转换为二进制格式configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb4.7 将config.json转换为区块二进制格式configtxlator proto_encode --input config.json --type common.Config --output config.pb4.8 生成修改前后通道配置的差异configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output diff_config.pb4.9 将配置的差异部分转换为JSON格式configtxlator proto_decode --input diff_config.pb --type common.ConfigUpdate | jq . > diff_config.json4.10 封装Fabric配置更新消息echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat diff_config.json)'}}}' | jq . > diff_config_envelope.json4.11 将配置更新消息转换为二进制格式configtxlator proto_encode --input diff_config_envelope.json --type common.Envelope --output diff_config_envelope.pb4.12 签名配置更新消息首先以Org1的管理员签名,设置环境变量:

  

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/mspexport CORE_PEER_ADDRESS=peer0.org1.example.com:7051export CORE_PEER_LOCALMSPID="Org1MSP"export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt然后签名:

  

peer channel signconfigtx -f diff_config_envelope.pb然后以Org2的管理员身份签名,设置环境变量:

  

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/mspexport CORE_PEER_ADDRESS=peer0.org2.example.com:7051export CORE_PEER_LOCALMSPID="Org2MSP"export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt签名:

  

peer channel signconfigtx -f diff_config_envelope.pb4.13 提交通道配置更新执行如下命令向排序节点提交通道更新交易:

  

peer channel update -f diff_config_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA现在让我们检查下效果。首先用Org1的Client调用链码:

  

  

果然失败了。接下来用Org2的Client调用链码:

  

  

和预期也一样,成功了。

  

原文链接:Hyperledger Fabric访问控制清单的配置与更新 - 汇智网

相关文章