Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of Fabric chain Code endorsement Strategy and ACL configuration

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

This article mainly shows you the "Fabric chain code endorsement strategy and ACL configuration example analysis", the content is easy to understand, well-organized, hope to help you solve your doubts, the following let the editor lead you to study and learn the "Fabric chain code endorsement strategy and ACL configuration example analysis" this article.

1. The basic concept of Hyperledger Fabric access control list / ACL

There are two types of access control policies in Hyperledger Fabric:

Signature policy: Signature Policies

Implicit meta-strategy: Implicit Meta Policies

The signature policy identifies a specific user by checking the signature in the request. For example:

Policies: MyPolicy: Type: Signature Rule: "Org1.Peer OR Org2.Peer"

The keywords supported by the signature policy include AND, OR, and NOutOf, which can be used to combine powerful access control rules, such as:

Requests signed by the administrator of institution A can be released.

Requests signed by more than half of the administrators in 20 institutions can be released.

Implicit meta-policy defines access control rules by aggregating descendant signature policies, which supports default access rules such as "requests signed by more than half of institutional administrators can be released." The definition method of implicit meta-policy is similar to but slightly different from signature policy, and its form is as follows:

The following is an example of an implicit meta-policy:

Policies: AnotherPolicy: Type: ImplicitMeta Rule: "MAJORITY Admins" 2. Default access control list for Hyperledger Fabric

The default access control rules are defined in configtx.yaml and are used for configtxgen to generate channel configurations. In the official configtx.yaml example, line 35 defines the signature policy, line 194 defines the implicit meta-policy, and line 131 defines the access control list / ACL.

3. Customize the access control list of Hyperledger Fabric

Let's edit the Application: ACLs section of configtx.yaml to modify the following:

Peer/Propose: / Channel/Application/Writers

Are:

Peer/Propose: / Channel/Application/MyPolicy

The definition of MyPolicy policy is as follows:

Policies: Readers: Type: ImplicitMeta Rule: "ANY Readers" Writers: Type: ImplicitMeta Rule: "ANY Writers" Admins: Type: ImplicitMeta Rule: "MAJORITY Admins" MyPolicy: Type: Signature Rule: "OR ('Org1MSP.client')"

The MyPolicy policy states that only the Client role can perform the corresponding tasks.

Don't forget to generate and update CA and administrator certificates.

Now let's try to call the chain code from Org1Client:

Now use Org2Client to call the chain code:

You can clearly see that peer/propose no longer accepts calls from ORG2's Client.

4. Dynamically update the ACL configuration of the Hyperledger Fabric channel

There are two ways to update access control policies:

Edit configtx.yaml, which is only applicable to new channels established later

Directly update the ACL configuration in a specific channel, which is applicable to existing channels

Below we will show how to update the access control list configuration in an existing channel.

Remember to start your Hyperledger Fabric network before doing the following.

4.1 access to the command line interface

Hyperledger Fabric has an automatically created cli container that provides a command line interface for manipulating nodes. Execute the following command to enter the cli interface:

Docker exec-it cli bash

Then set the environment variables that the program needs to use:

Export CHANNEL_NAME=mychannelexport 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.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 gets the current configuration of the specified Fabric channel

Execute the following command to get the current configuration of the channel and write to the file config_block.pb:

Peer channel fetch config config_block.pb-o orderer.example.com:7050-c $CHANNEL_NAME-- tls-- cafile $ORDERER_CA4.3 converts the channel configuration to JSON format

Config_block.pb is binary-encoded block configuration data. We need to convert it to JSON format that is easy to view and modify:

Configtxlator proto_decode-- input config_block.pb-- type common.Block | jq .data.data [0] .payload.data.config > config.json4.4 creates a JSON copy of the tunnel configuration for modification

Subsequent modifications will be made on the replica modified _ config.json:

Cp config.json modified_config.json4.5 modifies the channel configuration of the JSON copy

You can use any editor you like to modify the JSON copy, such as vim:

Vim modified_config.json

We changed the description of MyPolicy from Org1MSP to Org2MSP:

Remember to save it after modification.

4.6 convert the modified JSON copy of the channel configuration to the binary format configtxlator proto_encode-- input modified_config.json-- type common.Config-- output modified_config.pb4.7 convert the config.json to the block binary format configtxlator proto_encode-- input config.json-- type common.Config-- output config.pb4.8 to generate the difference of the channel configuration before and after the modification configtxlator compute_update-- channel_id $CHANNEL_NAME-- original config.pb -- updated modified_config.pb-- output diff_config.pb4.9 converts the differential part of the configuration to JSON format configtxlator proto_decode-- input diff_config.pb-- type common.ConfigUpdate | jq. > diff_config.json4.10 encapsulates Fabric configuration update message echo'{"payload": {"header": {"channel_header": {"channel_id": "mychannel", "type": 2}}, "data": {"config_update":'$(cat diff_config.json)'}}'| jq. > diff_config_envelope.json4.11 converts the configuration update message to binary format configtxlator proto_encode-- input diff_config_envelope.json-- type common.Envelope-- output diff_config_envelope.pb4.12 signature configuration update message

First, set the environment variable with the administrator's signature of 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

Then sign:

Peer channel signconfigtx-f diff_config_envelope.pb

Then sign as the administrator of Org2 and set the environment variable:

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

Signature:

Peer channel signconfigtx-f diff_config_envelope.pb4.13 submit channel configuration update

Execute the following command to submit the channel update transaction to the sorting node:

Peer channel update-f diff_config_envelope.pb-c $CHANNEL_NAME-o orderer.example.com:7050-- tls-- cafile $ORDERER_CA

Now let's check the results. First use the Client of Org1 to call the chain code:

It was a failure. Next, use the Client of Org2 to call the chain code:

As expected, it succeeded.

The above is all the contents of the article "sample Analysis of Fabric chain Code endorsement Strategy and ACL configuration". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report