Access Control Lists (ACL)¶

What is an Access Control List?¶

注意：本主题涉及通道管理级别的访问控制和策略。要了解链码中的访问控制，请参阅我们的链码开发者教程。

Fabric使用访问控制列表(ACL)来管理对资源的访问，方法是将一个策略与资源相关联，策略指定一个计算结果为true或false规则，给定一组标识。Fabric包含许多缺省ACL。在本文档中，我们将讨论如何格式化它们以及如何重写默认值。

但在此之前，有必要对资源和策略有一些了解。

Resources¶

用户通过指定用户链码、系统链码或事件流源与Fabric交互。因此，这些端点被认为是应该执行访问控制的“资源”。

应用程序开发人员需要了解这些资源以及与它们关联的默认策略。这些资源的完整列表可以在config .yaml中找到。您可以查看这里的configtx.yaml示例文件。

在configtx.yaml中命名的资源是Fabric当前定义的所有内部资源的详细列表。那里采用的宽松约定是<component>/<resource>。因此cscc/GetConfigBlock是CSCC组件中GetConfigBlock调用的资源。

Policies¶

策略是Fabric工作方式的基础，因为它们允许根据与实现请求所需的资源关联的策略检查与请求关联的身份(或一组身份)。背书策略用于确定交易是否得到了适当的背书。在通道配置中定义的策略被引用为访问控制策略的修改策略，并在通道配置本身中定义。

策略可以通过以下两种方式构建：签名策略或 ImplicitMeta策略。

`Signature` policies¶

这些策略指定了满足策略需要哪些用户签名。例如:

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

此策略结构可以解释为：名为MyPolicy的策略只能通过“来自Org1的节点”或“来自Org2的节点”角色的身份签名来满足。

签名策略支持AND、OR和NOutOf的任意组合，允许构造非常强大的规则，比如：“一个org A管理员和两个其他管理员，或者20个org管理员中的11个”。

`ImplicitMeta` policies¶

ImplicitMeta策略在配置层次结构的更深层上聚合最终由签名策略定义的策略结果。它们支持默认规则，比如“大多数组织管理员”。与签名策略相比，这些策略使用了不同但仍然非常简单的语法：<ALL|ANY|MAJORITY> <sub_policy>。

例如：任何读者或多数管理员。

注意，在默认策略配置中，管理员具有管理角色。指定只有管理员(或管理员的某些子集)才能访问资源的策略往往是针对敏感或网络管理方面(例如在通道上实例化链码)。写入者往往能够提议账本更新，比如交易，但通常没有管理权限。读者是一个被动的角色。他们可以获取信息，但没有提议更新账本的权限，也不能执行管理任务。这些默认策略可以添加、编辑或补充，例如通过新的节点和客户端角色(如果您有NodeOU支持)。

这里有一个ImplicitMeta策略结构的例子：

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

在这里，大多数管理员可以满足策略AnotherPolicy，其中管理员最终由下级的签名策略指定。

Where is access control specified?¶

访问控制默认值存在于configtx.yaml中, configtxgen用于构建通道的配置文件。

访问控制可以通过以下两种方式之一进行更新：编辑configtx.yaml，它将ACL更改传播到任何新通道，或者通过更新特定通道配置文件中的访问控制。

How ACLs are formatted in `configtx.yaml`¶

ACL的格式是键值对，由资源函数名后跟字符串组成。要查看这是什么样子，请参考这个示例文件configtx.yaml。

从这个例子中摘录了两段：

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

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

这些ACL定义了对节点/提议和事件/区块资源的访问，仅限于满足分别在正则路径/Channel/Application/Writers和/Channel/Application/Readers上定义的策略。

Updating ACL defaults in `configtx.yaml`¶

在引导网络时需要覆盖ACL默认值，或者在引导通道之前更改ACL的情况下，最佳实践将是更新config .yaml。

假设您想修改节点/提议的ACL默认值，它指定了在节点上调用链码的策略，从/Channel/Application/ writer到一个名为MyPolicy的策略。

这是通过添加一个名为MyPolicy的策略来实现的（它可以被称为任何名称，但在本例中，我们将其称为MyPolicy）。这个策略在configtx.yaml中的Application.Policies部分下定义，它指定了对于一个用户要授予或拒绝的访问授权。对于本例，我们将创建一个标识为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')"

然后，编辑configtx.yaml中的Application: ACLs部分，来修改 peer/Propose从下面的:

peer/Propose: /Channel/Application/Writers

到：

peer/Propose: /Channel/Application/MyPolicy

一旦在configtx中更改了这些字段，configtxgen工具将使用在创建通道创建交易时定义的策略和ACL。当联盟成员的管理员之一适当地签署并提交时，将已定义的acl和策略创建一个新通道。

一旦将MyPolicy引导到通道配置中，它还可以引用它来覆盖其他ACL默认值。例如:

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

这将限制SampleOrg.admin签署出块事件的能力。

如果已经创建了希望使用这个ACL的通道，则它们必须使用以下流程一次更新一个通道配置:

Updating ACL defaults in the channel config¶

如果已经创建了通道，希望使用MyPolicy限制对节点/提议的访问，或者希望创建不想让其他通道知道的ACL，则必须通过配置更新交易一次更新一个通道配置。

注意:通道配置交易是一个复杂的过程，我们不会在这里深入讨论。如果你想了解更多关于他们的信息，请查看我们关于通道配置更新的文档和我们的“向通道添加组织”教程。

在提取、翻译和剥离配置区块的元数据之后，您将通过在Application: policies下添加MyPolicy来编辑配置，管理员、编写者和读者策略已经位于Application: policies下。

"MyPolicy": {
  "mod_policy": "Admins",
  "policy": {
    "type": 1,
    "value": {
      "identities": [
        {
          "principal": {
            "msp_identifier": "SampleOrg",
            "role": "ADMIN"
          },
          "principal_classification": "ROLE"
        }
      ],
      "rule": {
        "n_out_of": {
          "n": 1,
          "rules": [
            {
              "signed_by": 0
            }
          ]
        }
      },
      "version": 0
    }
  },
  "version": "0"
},

特别注意这里的msp_identifer和角色。

然后，在配置的ACLs部分，从这里更改节点/提议 ACL:

"peer/Propose": {
  "policy_ref": "/Channel/Application/Writers"

到：

"peer/Propose": {
  "policy_ref": "/Channel/Application/MyPolicy"

注意：如果在通道配置中没有定义ACL，则必须添加整个ACL结构。

一旦更新了配置，就需要通过通常的通道更新流程来提交配置。

Satisfying an ACL that requires access to multiple resources¶

如果成员发出调用多个系统链码的请求，则必须满足所有这些系统链码的ACL。

例如，peer/ proposal引用通道上的任何提议请求。如果特定的提议需要访问两个系统链码，其中一个系统链码需要一个身份满足写入者，另一个系统链码需要一个身份满足MyPolicy，那么提交提议的成员必须有一个对写入者和MyPolicy都计算为“true”的身份。

在默认配置中，Writer是一个签名策略，其规则是SampleOrg.member。换句话说，是“我组织的任何成员”。上面列出的MyPolicy有一个SampleOrg.admin规则，或“我的组织的任何管理员”。为了满足这些ACL，成员必须同时是管理员和SampleOrg成员。默认情况下，所有管理员都是成员（虽然不是所有管理员都是成员），但是可以将这些策略改写为您希望它们成为的任何内容。因此，重要的是跟踪这些策略，以确保节点提议的ACL是可以满足的（除非这是意图）。

Migration considerations for customers using the experimental ACL feature¶

以前，访问控制列表的管理是在通道创建交易的isolated_data部分中完成的，并通过PEER_RESOURCE_UPDATE交易进行更新。最初，人们认为资源树将处理几个函数的更新，而这些函数最终是用其他方式处理的，因此维护一个单独的并行节点配置树被认为是不必要的。

使用v1.1中的实验资源树为客户迁移是可以的。由于官方v1.2版本不支持旧的ACL方法，网络操作者应该关闭所有的节点。然后，他们应该将它们升级到v1.2，提交一个通道重新配置交易，该交易启用v1.2功能并设置所需的ACL，最后重新启动升级的节点。重新启动的节点将立即使用新的通道配置并根据需要强制执行ACL。