Controlling Peer Access to Hyperledger Fabric Channels

Published in

Novai-Hyperledger Fabric 101

5 min readJun 3, 2024

In a Hyperledger Fabric network, not all peers are automatically allowed to join any channel. The permissions and policies that determine which peers can join a channel are controlled through the channel configuration and membership policies. This article will guide you through the process of configuring these permissions to allow or deny peers from joining a channel.

Key Terms

Consortium: A consortium is a group of organizations that are allowed to create and join channels within the network.
Channel Policies: Policies define the rules for who can read, write, and administer the channel. These policies control which organizations’ peers are allowed to join the channel.

Configuration Steps

1. Define Organizations and Consortium in `configtx.yaml`

The configtx.yaml file includes definitions for the organizations and the consortium. Here is an example snippet:

Organizations:
  - &Org1
    Name: Org1MSP
    ID: Org1MSP
    MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
    Policies:
      Readers:
        Type: Signature
        Rule: "OR('Org1MSP.member')"
      Writers:
        Type: Signature
        Rule: "OR('Org1MSP.member')"
      Admins:
        Type: Signature
        Rule: "OR('Org1MSP.admin')"
  - &Org2
    Name: Org2MSP
    ID: Org2MSP
    MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
    Policies:
      Readers:
        Type: Signature
        Rule: "OR('Org2MSP.member')"
      Writers:
        Type: Signature
        Rule: "OR('Org2MSP.member')"
      Admins:
        Type: Signature
        Rule: "OR('Org2MSP.admin')"

Consortiums:
  SampleConsortium:
    Organizations:
      - *Org1
      - *Org2

Let’s break down each rule:

Readers: This rule specifies who can read data from the channel. In the provided snippet, the rule is "OR('Org1MSP.member')". Here's what it means:
OR: It's a logical operator indicating that the condition inside it should be satisfied by at least one entity.
'Org1MSP.member': This refers to any member of the organization Org1MSP. The .member suffix implies any regular member of the organization, i.e., anyone who is part of the organization.
Writers: This rule determines who can write data to the channel. Similar to the Readers rule, it also employs an ORlogic and states that any member of Org1MSP can write to the channel.
Admins: This rule defines who has administrative privileges within the organization. The rule is "OR('Org1MSP.admin')", indicating that any member of Org1MSP with administrative permissions (typically defined by specific roles or attributes) can be considered an admin.

2. Define Channel Policies

Channel policies determine the permissions for various operations. For joining a channel, you typically need to set the Readers and Writers policies appropriately.

Profiles:
  TwoOrgsChannel:
    Consortium: SampleConsortium
    Application:
      <<: *ApplicationDefaults
      Organizations:
        - *Org1
        - *Org2
      Policies:
        Readers:
          Type: ImplicitMeta
          Rule: "ANY Readers"
        Writers:
          Type: ImplicitMeta
          Rule: "ANY Writers"
        Admins:
          Type: ImplicitMeta
          Rule: "MAJORITY Admins"

The snippet you provided specifies the access control policies for readers, writers, and administrators of a channel. Let’s break down each policy:

Readers: This policy defines who has permission to read data from the channel. The Type is set to ImplicitMeta, which is a type of policy that evaluates a set of policies and returns true if at least one of them evaluates to true. The Rule is "ANY Readers", which means that any entity (user or peer) with the "read" permission can access the channel. This policy essentially allows any reader to access the channel.
Writers: Similarly, this policy determines who can write data to the channel. It also uses the ImplicitMeta type with the rule "ANY Writers". This means that any entity with the "write" permission can write to the channel, allowing any writer to perform write operations on the channel.
Admins: This policy specifies who has administrative privileges within the channel. The Type is again ImplicitMeta, but the Rule is "MAJORITY Admins". Unlike the previous policies, this rule evaluates based on a majority vote from a designated set of administrators. This could mean that for an action to be considered authorized, it needs approval from a majority of administrators defined within the system.

Adapting the `network.sh` Script

The network.sh script includes functions for setting up the network, creating channels, and having peers join channels. Ensure that this script aligns with the permissions defined in your configtx.yaml.

Create Channel

Ensure the channel creation respects the consortium and policies.

function createChannel() {
  setGlobals 1
  peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/$CHANNEL_NAME.tx --outputBlock ./channel-artifacts/$CHANNEL_NAME.block
}

peer: This is the command-line interface (CLI) tool used to interact with the peer nodes in the Hyperledger Fabric network.
channel create: This is a sub-command of the peer CLI used to create a new channel.
-o orderer.example.com:7050: This specifies the address of the orderer node to which the channel creation request should be sent. In this case, it's orderer.example.com on port 7050.
-c $CHANNEL_NAME: This option specifies the name of the channel to be created. The variable $CHANNEL_NAME holds the name of the channel.
-f ./channel-artifacts/$CHANNEL_NAME.tx: This option specifies the path to the channel configuration transaction file ($CHANNEL_NAME.tx) that contains the configuration details for the new channel. The configuration transaction file typically contains information about the participating organizations, their policies, and other channel-related settings.
--outputBlock ./channel-artifacts/$CHANNEL_NAME.block: This option specifies the path where the generated channel block file will be saved. The channel block file ($CHANNEL_NAME.block) contains the initial configuration for the new channel, including cryptographic material and configuration details. It's the genesis block for the channel.

Join Channel

The joinChannel function must be called for each peer you want to join the channel.

function joinChannel() {
  ORG=$1
  setGlobals $ORG
  peer channel join -b ./channel-artifacts/$CHANNEL_NAME.block
}

Full Example for Joining Orgs to Channel

# Function to set environment variables for the organization's peers
function setGlobals() {
  ORG=$1
  if [ $ORG -eq 1 ]; then
    CORE_PEER_LOCALMSPID="Org1MSP"
    CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG1_CA
    CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
    CORE_PEER_ADDRESS=localhost:7051
  elif [ $ORG -eq 2 ]; then
    CORE_PEER_LOCALMSPID="Org2MSP"
    CORE_PEER_TLS_ROOTCERT_FILE=$PEER0_ORG2_CA
    CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
    CORE_PEER_ADDRESS=localhost:9051
  else
    echo "ORG Unknown"
    exit 1
  fi
}

# Function to join Org1's peers to the channel
function joinChannel() {
  ORG=$1
  setGlobals $ORG  peer channel join -b ./channel-artifacts/$CHANNEL_NAME.block
  verifyResult $? "peer0.org${ORG} failed to join the channel $CHANNEL_NAME"
}# Join both organizations' peers to the channel
function joinOrgsToChannel() {
  infoln "Joining Org1 peers to the channel..."
  joinChannel 1  infoln "Joining Org2 peers to the channel..."
  joinChannel 2
}# Main script execution starts here
# Set the channel name
CHANNEL_NAME=mychannel# Generate channel configuration transaction and create the channel
./network.sh createChannel# Join peers from both organizations to the channel
joinOrgsToChannel

Denying Access

To deny access, you can adjust the policies in configtx.yaml to exclude certain organizations or to set stricter rules. For example, to prevent Org2 from joining:

Policies:
  Readers:
    Type: Signature
    Rule: "OR('Org1MSP.member')"
  Writers:
    Type: Signature
    Rule: "OR('Org1MSP.member')"
  Admins:
    Type: Signature
    Rule: "OR('Org1MSP.admin')"

This policy only allows members of Org1 to read, write, and administer the channel.

Define permissions and consortiums in configtx.yaml: Specify which organizations are allowed to participate in the channel.
Configure channel policies: Set policies to control which organizations can read, write, and administer the channel.
Use network.sh to manage peers: Ensure that the script aligns with your defined policies when joining peers to the channel.

By correctly setting up these configurations, you can control which peers are allowed to join the channel and enforce the necessary permissions and policies. This setup ensures a secure and controlled blockchain network where only authorized participants can join and interact with the channels.