The first part of the file (Organizations) defines the organizations in the network. Default policies are set in each organization definition, Readers, Writers, Admins, and Endorsement, but you can define policy names arbitrarily. Each policy has a Type and Rule, Type describes the expression type of the policy (Signature or ImplicitMeta).
The BYFN example below shows the definition of the organization Org1 in the system channel, where the policy type is Signature and the endorsement policy rule is defined as "OR('Org1MSP.peer')", which means that peers in Org1MSP members are required to sign. It is these signature policies that form the sub-policies pointed to by the implicit meta-policy.
Click here to see an example of an organization defined with signature policies
The next example shows the ImplicitMeta policy type used in the Application section of the configtx.yaml. These set of policies lie on the /Channel/Application/ path. If you use the default set of Fabric ACLs, these policies define the behavior of many important features of application channels, such as who can query the channel ledger, invoke a chaincode, or update a channel config. These policies point to the sub-policies defined for each organization. The Org1 defined in the section above contains Reader, Writer, and Admin sub-policies that are evaluated by the Reader, Writer, and Admin ImplicitMeta policies in the Application section. Because the test network is built with the default policies, you can use the example Org1 to query the channel ledger, invoke a chaincode, and approve channel updates for any test network channel that you create.
Click here to see an example of ImplicitMeta policies
Fabric Chaincode Lifecycle
In the Fabric 2.0 release, a new chaincode lifecycle process was introduced, which is a more democratic process for governing chaincode in the network. The new process allows multiple organizations to vote on how the chaincode should behave before it is applied to the channel. This is important because this is the amalgamation of the new lifecycle process and the policies that are specified in the process determine the security of the network. More details about this process are in the operator's chaincode tutorial, but for the purposes of this topic, you should understand the use of policies in the process. The new process specification policy consists of two steps, when the chaincode is approved by members of the organization, and when it is committed to the channel.
The Application section of the configtx.yaml file contains the default chaincode lifecycle endorsement policy. In production you should customize this for your use case.
################################################################################
SECTION: Application
- This section defines the values to encode into a config transaction or
genesis block for application related parameters
################################################################################
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
# Policies defines the set of policies at this level of the config tree
# For Application policies, their canonical path is
# /Channel/Application/<PolicyName>
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
LifecycleEndorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
Endorsement:
Type: ImplicitMeta
Rule: "MAJORITY Endorsement"
The LifecycleEndorsement policy controls who needs to approve the chaincode definition.
The Endorsement policy is the default endorsement policy for chaincode. Read on for more details.
Chaincode endorsement policy
An endorsement policy is specified when a chaincode is approved and submitted to a channel using the Fabric chaincode lifecycle (this endorsement policy overrides all state associated with the chaincode). The endorsement policy can reference the endorsement policy in the channel configuration or explicitly specify the signing policy.
If the endorsement policy is not explicitly specified in the approval phase, the Endorsement policy "MAJORITY Endorsement" will be used by default, which means that most of the different channel members (organizations) need to execute and verify the transaction in order for the transaction to take effect. The default policy allows organizations joining the channel to automatically join the chaincode endorsement policy. If you don't want to use the default endorsement policy, you can use the signature policy format to specify more complex endorsement policies (thus requiring the chaincode to be first signed by one organization in the channel and then signed by other organizations).
Signature policies also allow you to include principals, which is an easy way to match roles and identities. Actors are similar to user IDs or group IDs, but are broader in that they can include attributes for a wider range of actor identities, such as an actor's organization, organizational unit, role, or even actor-assigned identities. The actors we discuss are the properties that determine their permissions. A role is described as 'MSP.ROLE', where MSP indicates the desired MSP ID (organization) and ROLE indicates one of four acceptable roles: Member, Admin, Client, and Peer. Roles are associated with users when they enroll with a CA. You can customize the list of roles available in Fabric CA.
Some valid protagonists:
'Org0.Admin': an administrator of Org0 MSP
'Org1.Member': a member of Org1 MSP
'Org1.Client': a client of Org1 MSP
'Org1.Peer': a peer node of Org1 MSP
'OrdererOrg. Orderer': An orderer for the OrdererOrg MSP
Some scenarios may require some special state (special key-value pairs, or the like) to have different endorsement policies. State-based endorsements can specify an endorsement policy for keys that differs from the default chaincode-level endorsement policy.
For more information on how to write an endorsement policy, see the Endorsement Policies topic in the how-to guide.
Note: The policies of different versions of Fabric are different:
Prior to Fabric 2.0, a chaincode's endorsement policy could be updated at chaincode instantiation or using chaincode lifecycle commands. If not specified at instantiation, the default endorsement policy is "any member of the organization in the channel". For example. In a channel with "Org1" and "Org2", there will be a default policy of "OR('Org1.member', 'Org2.member')".
Starting with Fabric 2.0, Fabric proposes a new chaincode lifecycle process that allows multiple organizations to agree on what to do with chaincode before it is applied to a channel. The new process requires organizations to agree to the parameters of the chaincode definition, such as name, version, and chaincode endorsement policy.
Overriding policy definitions
Hyperledger Fabric includes default policies for quick start, development, and testing, but needs to be customized in production. You should pay attention to the default policies in the configtx.yaml file. Channel configuration policies can be extended with any word, not just Readers, Writers, Admins in configtx.yaml. When you edit the configtx.yaml file to override the default policy of the ordering system channel or this specified channel and submit a configuration update, it will override the default policy of the ordering system and application channels.