Hyperledger Fabric中配置Org1全权限、Org2只读权限通道的方法

Got it, let's walk through how to lock down your existing two-org channel so Org1 has full read/write/admin access, while Org2 is restricted to read-only operations. This relies on adjusting channel-level access policies and chaincode endorsement policies—here's a step-by-step breakdown tailored to your setup:

1. Understand the Key Policies We’ll Modify #

Hyperledger Fabric uses policies to control access at two critical levels:

• Channel Policies: Govern who can read from the channel, write transactions to it, and manage channel configuration.
• Chaincode Endorsement Policies: Control which peers can endorse (approve) chaincode transactions—this ensures Org2 can’t submit valid write transactions.

2. Update Channel Configuration (For Existing Channel) #

Since your channel is already created, we can’t just edit configtx.yaml directly. Instead, we’ll fetch the current channel config, modify it, and submit the update.

Step 2.1: Fetch and Extract the Current Channel Config #

First, use Org1’s peer to pull the latest channel configuration block:

peer channel fetch config config_block.pb -o orderer.example.com:7050 -c mychannel

Convert the protobuf block to JSON:

configtxlator proto_decode --input config_block.pb --type common.Block --output config_block.json

Extract the core config section from the block:

jq .data.data[0].payload.data.config config_block.json > config.json

Make a copy to modify:

cp config.json modified_config.json

Step 2.2: Modify the Channel Policies #

Use jq to update the Readers, Writers, and Admins policies in modified_config.json:

• Readers: Include both Org1 and Org2 members (so Org2 can read)
• Writers: Restrict to only Org1 members (block Org2 from writing)
• Admins: Restrict to Org1 admins (full control for Org1)

Run these commands to apply the changes (replace mychannel and MSP names with your actual values):

# Update Readers policy
jq '.channel_group.groups.Application.policies.Readers.policy.value.rule = "OR('\''Org1MSP.member'\'', '\''Org2MSP.member'\'')"' modified_config.json > temp.json && mv temp.json modified_config.json

# Update Writers policy
jq '.channel_group.groups.Application.policies.Writers.policy.value.rule = "OR('\''Org1MSP.member'\'')"' modified_config.json > temp.json && mv temp.json modified_config.json

# Update Admins policy (optional, if you want Org1 to own channel management)
jq '.channel_group.groups.Application.policies.Admins.policy.value.rule = "OR('\''Org1MSP.admin'\'')"' modified_config.json > temp.json && mv temp.json modified_config.json

Step 2.3: Submit the Channel Config Update #

Convert the modified config back to protobuf and generate the update envelope:

# Encode original and modified configs to protobuf
configtxlator proto_encode --input config.json --type common.Config --output config.pb
configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb

# Compute the config difference
configtxlator compute_update --channel_id mychannel --original config.pb --updated modified_config.pb --output config_update.pb

# Convert update to JSON
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate --output config_update.json

# Wrap the update in a full envelope
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json

# Envelope to protobuf
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope --output config_update_in_envelope.pb

Finally, submit the update to the orderer:

peer channel update -f config_update_in_envelope.pb -c mychannel -o orderer.example.com:7050

3. Configure Chaincode Endorsement Policies #

Even if channel policies block Org2 from writing, we need to ensure their write transactions can’t get endorsed. When instantiating or upgrading your chaincode, set an endorsement policy that requires only Org1 peers to approve transactions.

Option 3.1: Set Policy During Chaincode Instantiation #

If you’re instantiating a new chaincode, use the -P flag to define the policy:

peer chaincode instantiate -o orderer.example.com:7050 -C mychannel -n mycc -v 1.0 -c '{"Args":["init","a","100","b","200"]}' -P "OR('Org1MSP.peer')"

Option 3.2: Update Policy for Existing Chaincode #

If your chaincode is already running, upgrade it with the new endorsement policy:

peer chaincode upgrade -o orderer.example.com:7050 -C mychannel -n mycc -v 1.1 -c '{"Args":["init","a","100","b","200"]}' -P "OR('Org1MSP.peer')"

4. Verify the Permissions #

Test to make sure the setup works as expected:

• Org2 Read Test: Use Org2’s peer to run a query—this should succeed:

  peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'
  

• Org2 Write Test: Try to submit a write transaction with Org2’s peer—this should fail (due to missing endorsement or channel write permissions):

  peer chaincode invoke -C mychannel -n mycc -c '{"Args":["invoke","a","b","10"]}'
  

• Org1 Full Access Test: Run both read and write transactions with Org1’s peer—both should complete successfully.

内容的提问来源于stack exchange，提问作者Achu