Fabric ACL入门

概念

ACL即Access Control Lists ，Fabric使用访问控制列表（ACL）通过将策略与资源相关联来管理对资源的访问，每个策略指定了给定一组标识的评估结果为true或false的规则。Fabric包含许多默认ACL。

• 资源：用户通过用户链码、 系统链码或事件流与Fabric进行交互。这些endpoint被当作在其上执行访问控制的“资源”。 采用命名惯例是/，如cscc/GetConfigBlock
• 策略：策略是Fabric工作的基础，策略允许将与请求关联的身份（或一组身份）与满足请求所需的资源相关联的策略进行检查。背书策略用于确定交易是否已得到适当背书。通道配置中定义的策略以及访问控制都称为修改策略，并且在通道配置本身中定义

策略类型

在Hyperledger Fabric中有两种类型的访问控制策略：

• 签名策略：Signature Policies
• 隐性元策略：Implicit Meta Policies

签名策略通过检查请求中的签名来识别特定的用户。例如：

Policies:
  MyPolicy:
    Type: Signature
    Rule: “Org1.Peer OR Org2.Peer”

签名策略支持的关键字包括：AND、OR和NOutOf，利用这几个关键字可以组合 出强大的访问控制规则，例如：

• A机构的管理员签名的请求可以放行
• 20个机构中超过半数的管理员签名的请求可以放行

隐性元策略则通过聚合签名策略来定义访问控制规则，它支持默认的访问 规则例如“超过半数的机构管理员签名的请求可以放行”。隐性元策略的定义方法 与签名策略类似但略有区别，其形式如下：

<ALL|ANY|MAJORITY> <sub_policy>

下面是一个隐性元策略的示例：

Policies:
  AnotherPolicy:
    Type: ImplicitMeta
    Rule: "MAJORITY Admins"

在这里，该策略AnotherPolicy可被满足MAJORITY的Admins，其中Admins为名称为Admins的签名策略（Signature Policies）。

默认访问控制清单

默认的访问控制规则定义在configtx.yaml中，用来供configtxgen生成通道配置。以下规则来源于官方源码sampleconfig的configtx.yaml。

/Channel/<Application|Orderer>//

 Policies: &SampleOrgPolicies
            Readers:
                Type: Signature
                Rule: "OR('SampleOrg.member')"
                # If your MSP is configured with the new NodeOUs, you might
                # want to use a more specific rule like the following:
                # Rule: "OR('SampleOrg.admin', 'SampleOrg.peer', 'SampleOrg.client')"
            Writers:
                Type: Signature
                Rule: "OR('SampleOrg.member')"
                # If your MSP is configured with the new NodeOUs, you might
                # want to use a more specific rule like the following:
                # Rule: "OR('SampleOrg.admin', 'SampleOrg.client')"
            Admins:
                Type: Signature
                Rule: "OR('SampleOrg.admin')"

/Channel/

    Policies:
        # Who may invoke the 'Deliver' API
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        # Who may invoke the 'Broadcast' API
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        # By default, who may modify elements at this config level
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

/Channel/Application/

    Policies: &ApplicationDefaultPolicies
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"

 ACLs: &ACLsDefault
        # This section provides defaults for policies for various resources
        # in the system. These "resources" could be functions on system chaincodes
        # (e.g., "GetBlockByNumber" on the "qscc" system chaincode) or other resources
        # (e.g.,who can receive Block events). This section does NOT specify the resource's
        # definition or API, but just the ACL policy for it.
        #
        # User's can override these defaults with their own policy mapping by defining the
        # mapping under ACLs in their channel definition

        #---Lifecycle System Chaincode (lscc) function to policy mapping for access control---#

        # ACL policy for lscc's "getid" function
        lscc/ChaincodeExists: /Channel/Application/Readers

        # ACL policy for lscc's "getdepspec" function
        lscc/GetDeploymentSpec: /Channel/Application/Readers

        # ACL policy for lscc's "getccdata" function
        lscc/GetChaincodeData: /Channel/Application/Readers

        # ACL Policy for lscc's "getchaincodes" function
        lscc/GetInstantiatedChaincodes: /Channel/Application/Readers

        #---Query System Chaincode (qscc) function to policy mapping for access control---#

        # ACL policy for qscc's "GetChainInfo" function
        qscc/GetChainInfo: /Channel/Application/Readers

        # ACL policy for qscc's "GetBlockByNumber" function
        qscc/GetBlockByNumber: /Channel/Application/Readers

        # ACL policy for qscc's  "GetBlockByHash" function
        qscc/GetBlockByHash: /Channel/Application/Readers

        # ACL policy for qscc's "GetTransactionByID" function
        qscc/GetTransactionByID: /Channel/Application/Readers

        # ACL policy for qscc's "GetBlockByTxID" function
        qscc/GetBlockByTxID: /Channel/Application/Readers

        #---Configuration System Chaincode (cscc) function to policy mapping for access control---#

        # ACL policy for cscc's "GetConfigBlock" function
        cscc/GetConfigBlock: /Channel/Application/Readers

        # ACL policy for cscc's "GetConfigTree" function
        cscc/GetConfigTree: /Channel/Application/Readers

        # ACL policy for cscc's "SimulateConfigTreeUpdate" function
        cscc/SimulateConfigTreeUpdate: /Channel/Application/Readers

        #---Miscellanesous peer function to policy mapping for access control---#

        # ACL policy for invoking chaincodes on peer
        peer/Propose: /Channel/Application/Writers

        # ACL policy for chaincode to chaincode invocation
        peer/ChaincodeToChaincode: /Channel/Application/Readers

        #---Events resource to policy mapping for access control###---#

        # ACL policy for sending block events
        event/Block: /Channel/Application/Readers

        # ACL policy for sending filtered block events
        event/FilteredBlock: /Channel/Application/Readers

/Channel/Orderer/

    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        # BlockValidation specifies what signatures must be included in the block
        # from the orderer for the peer to validate it.
        BlockValidation:
            Type: ImplicitMeta
            Rule: "ANY Writers"

更新ACL默认值 configtx.yaml

如果在引导网络时有必要覆盖ACL默认值，或者在引导通道之前更改ACL，则最佳实践是更新 configtx.yaml。

假设您想将peer/Propose ACL默认值（指定用于在同级上调用链码/Channel/Application/Writers 的策略）从修改为MyPolicy。

可以通过添加名称为的MyPolicy策略来完成（可以将其命名成任何名字，但在本示例中，我们将其称为MyPolicy）。该策略在Application.Policies内部部分中定义， configtx.yaml并指定要检查的规则以授予或拒绝用户访问权限。在此示例中，我们将创建一个 Signature策略标识SampleOrg.admin。

Policies: &ApplicationDefaultPolicies
    Readers:
        Type: ImplicitMeta
        Rule: "ANY Readers"
    Writers:
        Type: ImplicitMeta
        Rule: "ANY Writers"
    Admins:
        Type: ImplicitMeta
        Rule: "MAJORITY Admins"
    MyPolicy:
        Type: Signature
        Rule: "OR('SampleOrg.admin')"

然后，编辑其中的Application: ACLs部分configtx.yaml以peer/Propose对此进行更改 ：

peer/Propose: /Channel/Application/Writers

修改为：

peer/Propose: /Channel/Application/MyPolicy

在中更改这些字段后configtx.yaml，该configtxgen工具将使用在创建渠道创建交易时定义的策略和ACL。由联盟成员的一位管理员适当签名并提交后，将创建一个具有定义的ACL和策略的新渠道。

一旦MyPolicy被引导进入通道配置，也可以引用它来覆盖其他ACL默认值。例如：

SampleSingleMSPChannel:
    Consortium: SampleConsortium
    Application:
        <<: *ApplicationDefaults
        ACLs:
            <<: *ACLsDefault
            event/Block: /Channel/Application/MyPolicy

这将限制向订阅事件的功能SampleOrg.admin。