0

I'm trying Fabric v2.2 and keeps failed to join a peer to channel because of some policies problem (I guess). To get MSPs of orderers and peers, I used CAs of an orderer organization and a peer organization (there is one peer organization).

fabric-ca-client register -d --id.name ${PEERS[$i]} --id.secret ${PEER_ADMIN_PWS[$i]} --id.type peer -u https://$CA_NODE:7054
…
fabric-ca-client register -d --id.name $ORG_ADMIN_ID --id.secret $ORG_ADMIN_PW --id.type admin -u https://$CA_NODE:7054
….
fabric-ca-client register -d --id.name ${ORDERERS[$i]} --id.secret ${ORDERER_ADMIN_PWS[$i]} --id.type orderer -u https://$CA_NODE:7054

…
fabric-ca-client enroll -d -u https://${NODES[$i]}:${NODE_ADMIN_PWS[$i]}@$CA_NODE:7054

I think MSPs were okay because the network was up well.

Then, I launched a CLI container and create a channel called identitych. I think it worked well because I checked the identitych directory had been created under chains directory of all orderers.

After that, when I proposed to join a peer to a channel with the following command, the orderer could not deliver a block to a peer because of the permission denied and a peer could not retrieve a block from the orderer because of FORBIDDEN problem.

peer channel join -b /channel-artifacts/identitych.block

My configtx.yaml file looks like:

Organizations:
  - &BPLOrdererOrg
    Name: BPLOrdererMSP
    ID: BPLOrdererMSP
    MSPDir: ./orderers/org-msp

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

    OrdererEndpoints:
      - orderer0.common.bpl:7050

  - &BPLOrg
    Name: BPLMSP
    ID: BPLMSP
    MSPDir: ./peers/org-msp

    Policies:
      Readers:
        Type: Signature
        Rule: "OR('BPLMSP.admin', 'BPLMSP.peer', 'BPLMSP.client')"
      Writers:
        Type: Signature
        Rule: "OR('BPLMSP.admin', 'BPLMSP.client')"
      Admins:
        Type: Signature
        Rule: "OR('BPLMSP.admin')"
      Endorsement:
        Type: Signature
        Rule: "OR('BPLMSP.peer')"

NodeOUs is enabled by placing config.yaml on msp directory of each orderer and peer.

# config.yaml
NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "client"
  AdminOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "admin"
  PeerOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "peer"
  OrdererOUIdentifier:
    Certificate: "cacerts/cacert.pem"
    OrganizationalUnitIdentifier: "orderer"

Repeatedly, the orderer prints the following warning:

2020-08-20 11:35:08.041 UTC [comm.grpc.server] 1 -> INFO 0c3 streaming call completed grpc.service=orderer.AtomicBroadcast grpc.method=Deliver grpc.peer_address=172.24.0.11:42642 grpc.code=OK grpc.call_duration=792.5µs
2020-08-20 11:35:15.176 UTC [common.deliver] deliverBlocks -> WARN 0c4 [channel: identitych] Client 172.24.0.8:60236 is not authorized: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied

At the same time, a peer repeatedly prints the following warning too:

2020-08-20 11:34:28.604 UTC [peer.blocksprovider] DeliverBlocks -> WARN 02b Got error while attempting to receive blocks: received bad status FORBIDDEN from orderer channel=identitych orderer-address=orderer0.common.bpl:7050
2020-08-20 11:34:28.604 UTC [peer.blocksprovider] func1 -> WARN 02c Encountered an error reading from deliver stream: EOF channel=identitych orderer-address=orderer0.common.bpl:7050

I found a similar question and answer (link) and I'm curious about the following quote:

Check for the Reader policies that you have defined in your configtx.yaml this error is generated because of the policy mismatch. You have defined some specific user type(admin, peer, client) in your Reader policies but this specific user type is not passed into certificates that you have generated for your peer.

I agree with that my problem is because of the policy mismatch, but I don't understand the following mention:

but this specific user type is not passed into certificates that you have generated for your peer.

How can I solve my issue? Thanks, in advance.

byron1st
  • 969
  • 1
  • 13
  • 35

1 Answers1

1

It looks like you've not enabled NodeOUs for the MSP definitions included in the channel configuration.

NodeOUs is enabled by placing config.yaml on msp directory of each orderer and peer.

This will enable NodeOU support in the 'local MSP' of the peer and orderer, but for channel operations, like invoking the Deliver API, it is the channel MSP definition which is utilized.

Make sure that you have placed your config.yaml in the MSP directory referenced by your configtx.yaml (for instance, in your case under ./peers/org-msp) before generating your genesis block for the orderer system channel.

Additional notes:

You can confirm that it is NodeOU related by changing the Readers policy in your configtx.yaml to refer to member for your peer org, like you have for the orderer org. If things work with the member policy, then this is definitely NodeOU related.

You could also turn up debugging for the policy evaluation by setting FABRIC_LOGGING_SPEC=info:cauthdsl=debug:policies=debug:msp=debug. This is generally too verbose for normal operation, but will give you a more clear audit trail of exactly what's causing the failure.

Jason Yellick
  • 1,584
  • 9
  • 12