Hyperledger Fabric权限进阶篇
對于Fabric的權限和MSP配置這塊，可能大家實際部署會給一堆msp目錄繞暈，我們回過頭來梳理一下。
1.Peer節點如何控制用戶的采訪權限？
我們以first-network為例, 先看下peer0的啟動配置docker-compose-cli.yaml。
引用到base/docker-compose-base.yaml
peer0.org1.example.com:container_name: peer0.org1.example.comextends:file: peer-base.yamlservice: peer-baseenvironment:- CORE_PEER_ID=peer0.org1.example.com- CORE_PEER_ADDRESS=peer0.org1.example.com:7051- CORE_PEER_GOSSIP_BOOTSTRAP=peer1.org1.example.com:7051- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer0.org1.example.com:7051- CORE_PEER_LOCALMSPID=Org1MSPvolumes:- /var/run/:/host/var/run/- ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp- ../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls:/etc/hyperledger/fabric/tls- peer0.org1.example.com:/var/hyperledger/productionports:- 7051:7051- 7053:7053引用到base/peer-base.yaml
services:peer-base:image: hyperledger/fabric-peer:$IMAGE_TAGenvironment:- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock# the following setting starts chaincode containers on the same# bridge network as the peers# https://docs.docker.com/compose/networking/- CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=${COMPOSE_PROJECT_NAME}_byfn- CORE_LOGGING_LEVEL=INFO#- CORE_LOGGING_LEVEL=DEBUG- CORE_PEER_TLS_ENABLED=true- CORE_PEER_GOSSIP_USELEADERELECTION=true- CORE_PEER_GOSSIP_ORGLEADER=false- CORE_PEER_PROFILE_ENABLED=true- CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/fabric/tls/server.crt- CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/fabric/tls/server.key- CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/tls/ca.crtworking_dir: /opt/gopath/src/github.com/hyperledger/fabric/peercommand: peer node startpeer node start啟動節點peer0.org1.example.com
環境變量CORE_PEER_MSPCONFIGPATH這里沒有顯示聲明, 默認值應該是對應docker容器里面的/etc/hyperledger/fabric/msp
藍色部分的卷映射指向主機的
../crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp
(1)cacerts
文件夾放置的用于身份識別的ca根證書, 回憶下基礎篇的會員身份使用PKI等數字簽名技術用于識別客戶身份(這里特指可連接到peer節點的客戶端)。
一個組織對一個根CA(不考慮中間CA情況), 所以組織org1下的peer0和peer1實際配置的是同一個ca.org1.example.com-cert.pem， 所以這個文件夾應該放的是對應組織的CA根證書
[root@k8s-master cacerts]# pwd /mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/cacerts [root@k8s-master cacerts]# ll 總用量 4 -rw-r--r--. 1 root root 843 9月 29 10:32 ca.org1.example.com-cert.pem假裝專業些給大家看下證書內容
[root@k8s-master cacerts]# openssl x509 -in ca.org1.example.com-cert.pem -noout -text Certificate:Data:Version: 3 (0x2)Serial Number:17:b3:7f:af:19:79:82:d1:1d:78:86:fb:97:10:e7:50Signature Algorithm: ecdsa-with-SHA256Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.comValidityNot Before: Sep 29 02:27:16 2018 GMTNot After : Sep 26 02:27:16 2028 GMTSubject: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.comSubject Public Key Info:Public Key Algorithm: id-ecPublicKeyPublic-Key: (256 bit)pub: 04:13:93:55:07:a9:bf:a1:19:7d:21:c0:ee:2d:2a:94:d4:e6:9b:27:35:c9:56:f4:72:81:a1:41:08:96:77:b6:6b:2b:c9:fa:78:b7:07:fe:a1:db:20:e5:1c:88:1b:94:7b:57:6f:e4:47:5c:ab:a5:fe:dd:c1:ff:30:9f:2a:02:aeASN1 OID: prime256v1NIST CURVE: P-256X509v3 extensions:X509v3 Key Usage: criticalDigital Signature, Key Encipherment, Certificate Sign, CRL SignX509v3 Extended Key Usage: Any Extended Key UsageX509v3 Basic Constraints: criticalCA:TRUEX509v3 Subject Key Identifier: F3:40:31:60:A2:2B:B9:CB:B5:FD:10:24:E1:BA:65:D9:8D:2C:E4:E1:AB:51:FB:55:6B:17:35:E1:11:CF:6E:82Signature Algorithm: ecdsa-with-SHA25630:44:02:20:03:84:0c:0e:e5:12:dd:77:af:5d:cc:ea:a3:f0:e2:e4:b5:8a:b2:36:7c:27:9b:e9:6d:e0:8a:e4:c1:97:7b:33:02:20:7b:bf:6e:2b:f5:fc:94:18:cf:db:f0:55:15:ea:22:7c:ee:df:38:30:04:33:b0:81:7b:08:b1:79:44:4c:42:d7 [root@k8s-master cacerts]#(2)config.yaml
主要配置的可采訪的組織單元，也就是說X.509 PEM證書里面的OU(組織單元)要么是client或者peer才能采訪當前節點。
對于這里的Certification配置也有一些疑惑, cacerts文件夾使用根CA證書確定了連接客戶身份，這里的config.yaml算是第二層過濾吧, 每個不同類型的組織單元OUIdentifier的Certificate應該不能對應其它的CA根證書，應該只能是同一個CA根證書或者不同的中間CA證書。
OU=client的證書實際上后面會看到admincerts是OU=client, org1下的
User1@org1.example.com用戶也是OU=client, 貌似外部接入peer節點的用戶都歸到OU=client.
OU=peer的證書暫時只有peer節點自身的證書，例如peer0,peer1都是OU=peer
/mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/signcerts/peer0.org1.example.com-cert.pem
實際OU=client和peer的有什么不同權限，筆者估計是peer是標記不同peer節點的調用， 或者是在鏈碼安裝的時候可以指定不同的OU
config.yaml的配置是可選的, 它是通過crypto-config.yaml下org設置了EnableNodeOUs: true才默認會生成MSP模板。
(3)keystore
存放的peer0節點的私鑰，可以用于數字簽名。
私鑰內容
——-BEGIN PRIVATE KEY——-
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgMJM5N0U+nS8GYarY
GwQfj++skU1ttNDj9xalBVZrUOShRANCAASQemtTNZXyQktIv1XrWqRItxB6ldSp
PWWszknMJvRetGBMG03ekUeeNeIDbdQSiLhcjttWfBZgMxZziEXqj22O
——-END PRIVATE KEY——-
(4)signcerts
存放的是peer0被ca.org1.example.com簽名的證書。注意到藍色部分, OU=peer
[root@k8s-master msp]# cd signcerts/ [root@k8s-master signcerts]# ll 總用量 4 -rw-r--r--. 1 root root 810 9月 29 10:32 peer0.org1.example.com-cert.pem [root@k8s-master signcerts]# vim peer0.org1.example.com-cert.pem [root@k8s-master signcerts]# openssl x509 -in peer0.org1.example.com-cert.pem -noout -text Certificate:Data:Version: 3 (0x2)Serial Number:97:ca:cf:78:35:11:e4:02:f7:c8:a9:52:61:b6:e6:44Signature Algorithm: ecdsa-with-SHA256Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.comValidityNot Before: Sep 29 02:27:16 2018 GMTNot After : Sep 26 02:27:16 2028 GMTSubject: C=US, ST=California, L=San Francisco, OU=peer, CN=peer0.org1.example.comSubject Public Key Info:Public Key Algorithm: id-ecPublicKeyPublic-Key: (256 bit)pub: 04:90:7a:6b:53:35:95:f2:42:4b:48:bf:55:eb:5a:a4:48:b7:10:7a:95:d4:a9:3d:65:ac:ce:49:cc:26:f4:5e:b4:60:4c:1b:4d:de:91:47:9e:35:e2:03:6d:d4:12:88:b8:5c:8e:db:56:7c:16:60:33:16:73:88:45:ea:8f:6d:8eASN1 OID: prime256v1NIST CURVE: P-256X509v3 extensions:X509v3 Key Usage: criticalDigital SignatureX509v3 Basic Constraints: criticalCA:FALSEX509v3 Authority Key Identifier: keyid:F3:40:31:60:A2:2B:B9:CB:B5:FD:10:24:E1:BA:65:D9:8D:2C:E4:E1:AB:51:FB:55:6B:17:35:E1:11:CF:6E:82Signature Algorithm: ecdsa-with-SHA25630:45:02:21:00:d2:c3:79:5f:cc:95:be:6c:39:bc:b0:ee:ce:c2:95:d7:59:2b:b3:30:fc:f3:4c:ae:cb:5a:16:9b:90:43:87:a9:02:20:5d:ab:06:b6:7d:8d:23:bc:20:2b:e2:66:59:31:35:d6:35:a3:e3:bf:3d:5c:3a:13:e9:f2:b9:71:b4:b0:1c:4f [root@k8s-master signcerts]#(5)tlscacerts
如果peer0啟用了TLS保證安全和校驗，就必須指定tlscacerts證書了，一般使用與cacerts不同的ca證書會安全些。 證書內容如下：
[root@k8s-master tlscacerts]# ll 總用量 4 -rw-r--r--. 1 root root 855 9月 29 10:32 tlsca.org1.example.com-cert.pem [root@k8s-master tlscacerts]# openssl x509 -in tlsca.org1.example.com-cert.pem -noout -text Certificate:Data:Version: 3 (0x2)Serial Number:7a:fa:31:77:69:bb:28:fc:b9:3d:81:98:7b:f3:83:64Signature Algorithm: ecdsa-with-SHA256Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=tlsca.org1.example.comValidityNot Before: Sep 29 02:27:16 2018 GMTNot After : Sep 26 02:27:16 2028 GMTSubject: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=tlsca.org1.example.comSubject Public Key Info:Public Key Algorithm: id-ecPublicKeyPublic-Key: (256 bit)pub: 04:92:79:62:41:43:06:7d:30:65:ef:2c:ae:87:8e:41:f6:12:27:f0:9f:a0:c1:3d:f1:03:3d:ee:e7:45:87:58:72:f7:a0:24:85:d8:3d:01:42:d2:01:15:fc:e1:8a:d8:6b:56:0c:25:e2:98:8d:09:fb:0e:a5:65:ea:4a:ec:a0:06ASN1 OID: prime256v1NIST CURVE: P-256X509v3 extensions:X509v3 Key Usage: criticalDigital Signature, Key Encipherment, Certificate Sign, CRL SignX509v3 Extended Key Usage: Any Extended Key UsageX509v3 Basic Constraints: criticalCA:TRUEX509v3 Subject Key Identifier: 25:41:EA:7D:4B:4F:14:0B:13:6D:E1:EE:09:AA:00:A6:90:66:B4:2B:2F:90:6B:DF:E2:EF:D6:59:AE:17:40:4BSignature Algorithm: ecdsa-with-SHA25630:45:02:21:00:cd:3b:23:ed:fb:2b:de:bf:64:87:f0:af:f6:0a:02:5f:26:83:ff:32:08:58:16:23:ba:30:36:b5:ee:aa:c9:55:02:20:4b:40:a8:89:c7:2d:0c:8f:c0:b6:34:9a:72:f0:47:0e:66:8a:85:7b:d6:51:d6:1f:75:1e:e6:03:40:95:09:c9參考peer-base.yaml是開啟了TLS的 - CORE_PEER_TLS_ENABLED=true
(6)admincerts
這里存放的是整個組織org1的管理員證書, 和
/mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com下的簽名證書是一致的， peer1.org1.example.com節點也是如此。
就是說執行cryptogen generate —config=./crypto-config.yaml默認就是讓org1下的所有peer都有相同的admin.
如果peer0和peer1的admincerts不一樣，應該會有問題,第二個問題我們會查看下創世塊的具體內容，里面指定的是組織的admin而不會有節點的admin。
話說這個admin的權限就比較大了，可以把peer節點加入到channel, 可以安裝和實例化chaincode。BYFN里面容器里面執行的peer命令實際對應的都是admin的msp.
[root@k8s-master admincerts]# pwd /mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/admincerts [root@k8s-master admincerts]# ll 總用量 4 -rw-r--r--. 1 root root 810 9月 29 10:32 Admin@org1.example.com-cert.pem我們看下組織管理員證書的內容, OU=client
[root@k8s-master admincerts]# openssl x509 -in Admin\@org1.example.com-cert.pem -noout -text Certificate:Data:Version: 3 (0x2)Serial Number:48:15:46:a1:6c:25:63:98:c7:e9:c5:26:b8:67:f9:53Signature Algorithm: ecdsa-with-SHA256Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.comValidityNot Before: Sep 29 02:27:16 2018 GMTNot After : Sep 26 02:27:16 2028 GMTSubject: C=US, ST=California, L=San Francisco, OU=client, CN=Admin@org1.example.comSubject Public Key Info:Public Key Algorithm: id-ecPublicKeyPublic-Key: (256 bit)pub: 04:59:01:48:99:af:c8:30:17:e2:5a:b4:ee:5a:1c:c6:79:a7:c5:3a:14:20:d1:a0:39:de:13:5e:99:c6:d1:4e:9c:cd:63:fb:73:96:9f:b4:48:60:4f:8e:72:10:ee:54:19:33:5f:dc:29:e2:94:39:b3:4e:f2:d3:cd:1f:3d:0a:54ASN1 OID: prime256v1NIST CURVE: P-256X509v3 extensions:X509v3 Key Usage: criticalDigital SignatureX509v3 Basic Constraints: criticalCA:FALSEX509v3 Authority Key Identifier: keyid:F3:40:31:60:A2:2B:B9:CB:B5:FD:10:24:E1:BA:65:D9:8D:2C:E4:E1:AB:51:FB:55:6B:17:35:E1:11:CF:6E:82Signature Algorithm: ecdsa-with-SHA25630:44:02:20:0c:be:41:5b:58:1e:df:7e:78:5d:77:00:44:c7:a1:c8:2f:e1:6b:bb:8a:ac:b2:26:aa:ab:35:f6:f5:4b:66:6d:02:20:46:b7:32:c2:4f:a1:d0:89:20:32:42:35:50:80:8e:9e:ba:66:d6:b2:6b:55:1f:e0:b5:5f:2c:04:be:b0:6c:1e小結:
PEER作為接入點, 主要也是靠本地的MSP去識別用戶身份，判斷用戶是否是所信任的CA頒發證書， 再結合組織單元等確定用戶是否可采訪節點。
2.Channel是如何控制不同組織或peer節點的接入權限的？
一個channel對應一個ledger賬本, 也可以說對應一條區塊鏈，怎么控制采訪賬本的用戶呢？
先看BYFN如何創建channel：
cryptogen generate --config=./crypto-config.yaml export CHANNEL_NAME=mychannel configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAMEChannel.tx實際是創建通道的請求報文內容，看下configtx.yaml的TwoOrgsChannel profile對應的聯盟和通道應用，包含了Org1和Org2, 即mychannel通道允許org1或org2下的用戶采訪。
Profiles:TwoOrgsOrdererGenesis:Capabilities:<<: *ChannelCapabilitiesOrderer:<<: *OrdererDefaultsOrganizations:- *OrdererOrgCapabilities:<<: *OrdererCapabilitiesConsortiums:SampleConsortium:Organizations:- *Org1- *Org2TwoOrgsChannel:Consortium: SampleConsortiumApplication:<<: *ApplicationDefaultsOrganizations:- *Org1- *Org2Capabilities:<<: *ApplicationCapabilitiesOrganizations:# SampleOrg defines an MSP using the sampleconfig. It should never be used# in production but may be used as a template for other definitions- &OrdererOrg# DefaultOrg defines the organization which is used in the sampleconfig# of the fabric.git development environmentName: OrdererOrg# ID to load the MSP definition asID: OrdererMSP# MSPDir is the filesystem path which contains the MSP configurationMSPDir: crypto-config/ordererOrganizations/example.com/msp- &Org1# DefaultOrg defines the organization which is used in the sampleconfig# of the fabric.git development environmentName: Org1MSP# ID to load the MSP definition asID: Org1MSPMSPDir: crypto-config/peerOrganizations/org1.example.com/mspAnchorPeers:# AnchorPeers defines the location of peers which can be used# for cross org gossip communication. Note, this value is only# encoded in the genesis block in the Application section context- Host: peer0.org1.example.comPort: 7051- &Org2# DefaultOrg defines the organization which is used in the sampleconfig# of the fabric.git development environmentName: Org2MSP# ID to load the MSP definition asID: Org2MSPMSPDir: crypto-config/peerOrganizations/org2.example.com/mspAnchorPeers:# AnchorPeers defines the location of peers which can be used# for cross org gossip communication. Note, this value is only# encoded in the genesis block in the Application section context- Host: peer0.org2.example.comPort: 7051我們假裝專業些查看下channel.tx的內容
[root@k8s-master first-network]# configtxgen -profile TwoOrgsChannel -channelID mychannel -inspectChannelCreateTx ./channel-artifacts/channel.tx 2018-10-11 16:37:24.650 CST [common/tools/configtxgen] main -> INFO 001 Loading configuration 2018-10-11 16:37:24.663 CST [common/tools/configtxgen] doInspectChannelCreateTx -> INFO 002 Inspecting transaction 2018-10-11 16:37:24.663 CST [common/tools/configtxgen] doInspectChannelCreateTx -> INFO 003 Parsing transaction {"payload": {"data": {"config_update": {"channel_id": "mychannel","read_set": {"groups": {"Application": {"groups": {"Org1MSP": {"mod_policy": "","version": "0"},"Org2MSP": {"mod_policy": "","version": "0"}},"mod_policy": "","version": "0"}},"mod_policy": "","values": {"Consortium": {"mod_policy": "","version": "0"}},"version": "0"},"write_set": {"groups": {"Application": {"groups": {"Org1MSP": {"mod_policy": "","version": "0"},"Org2MSP": {"mod_policy": "","version": "0"}},"mod_policy": "Admins","policies": {"Admins": {"mod_policy": "Admins","policy": {"type": 3,"value": {"rule": "MAJORITY","sub_policy": "Admins"}},"version": "0"},"Readers": {"mod_policy": "Admins","policy": {"type": 3,"value": {"rule": "ANY","sub_policy": "Readers"}},"version": "0"},"Writers": {"mod_policy": "Admins","policy": {"type": 3,"value": {"rule": "ANY","sub_policy": "Writers"}},"version": "0"}},"values": {"Capabilities": {"mod_policy": "Admins","value": {"capabilities": {"V1_2": {}}},"version": "0"}},"version": "1"}},"mod_policy": "","values": {"Consortium": {"mod_policy": "","value": {"name": "SampleConsortium"},"version": "0"}},"version": "0"}}},"header": {"channel_header": {"channel_id": "mychannel","epoch": "0","timestamp": "2018-10-11T07:13:13.000Z","tx_id": "","type": 2,"version": 0}}} }我們大概的看下這個交易json請求內容即可，主要是定義了更新channel的報文，定義了對應組織的讀寫，管理權限。
我們主要掌握配置configtx.yaml（BYFN的configtx.yaml簡單了些，無法體現出讀寫，管理的權限配置）。 我們這次深入學習官方的sampleconfig下完整例子。
參考
https://hyperledger-fabric.readthedocs.io/en/release-1.2/access_control.html
完整一些的configtx.yaml可以參考
https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/configtx.yaml
Policy定義兩種
(1)簽名策略/signature policies
Organizations:# SampleOrg defines an MSP using the sampleconfig. It should never be used# in production but may be used as a template for other definitions.- &SampleOrg# Name is the key by which this org will be referenced in channel# configuration transactions.# Name can include alphanumeric characters as well as dots and dashes.Name: SampleOrg# ID is the key by which this org's MSP definition will be referenced.# ID can include alphanumeric characters as well as dots and dashes.ID: SampleOrg# MSPDir is the filesystem path which contains the MSP configuration.MSPDir: msp# Policies defines the set of policies at this level of the config tree# For organization policies, their canonical path is usually# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>Policies: &SampleOrgPoliciesReaders:Type: SignatureRule: "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: SignatureRule: "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: SignatureRule: "OR('SampleOrg.admin')"# AnchorPeers defines the location of peers which can be used for# cross-org gossip communication. Note, this value is only encoded in# the genesis block in the Application section context.AnchorPeers:- Host: 127.0.0.1 Port: 7051簡單點說就是證書里面不是有organization(O=xx)和organizationUnit(OU=xx), 結合邏輯關系操作符OR, AND, NOutOf
(2)ImplicitMeta 隱式標簽
Channel: &ChannelDefaults# Policies defines the set of policies at this level of the config tree# For Channel policies, their canonical path is# /Channel/<PolicyName>Policies:# Who may invoke the 'Deliver' APIReaders:Type: ImplicitMetaRule: "ANY Readers"# Who may invoke the 'Broadcast' APIWriters:Type: ImplicitMetaRule: "ANY Writers"# By default, who may modify elements at this config levelAdmins:Type: ImplicitMetaRule: "MAJORITY Admins"# Capabilities describes the channel level capabilities, see the# dedicated Capabilities section elsewhere in this file for a full# descriptionCapabilities: <<: *ChannelCapabilitiesRule語法 .
MAJORITY - 滿足主要的子組的策略, 上面例子的Admins應該是下一級的signature policy
ANY - 滿足任意子組的policy
ALL - 滿足所有的子組的policy
那這些POLICY怎么使用呢？通常結合ACL配置Resource的采訪權限，Resource基本定義為 系統或用戶的chaincode, 和系統消息資源， 我們看個例子：
Application: &ApplicationDefaultsACLs: &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" functionlscc/ChaincodeExists: /Channel/Application/Readers# ACL policy for lscc's "getdepspec" functionlscc/GetDeploymentSpec: /Channel/Application/Readers# ACL policy for lscc's "getccdata" functionlscc/GetChaincodeData: /Channel/Application/Readers# ACL Policy for lscc's "getchaincodes" functionlscc/GetInstantiatedChaincodes: /Channel/Application/Readers#---Query System Chaincode (qscc) function to policy mapping for access control---## ACL policy for qscc's "GetChainInfo" functionqscc/GetChainInfo: /Channel/Application/Readers# ACL policy for qscc's "GetBlockByNumber" functionqscc/GetBlockByNumber: /Channel/Application/Readers# ACL policy for qscc's "GetBlockByHash" functionqscc/GetBlockByHash: /Channel/Application/Readers# ACL policy for qscc's "GetTransactionByID" functionqscc/GetTransactionByID: /Channel/Application/Readers# ACL policy for qscc's "GetBlockByTxID" functionqscc/GetBlockByTxID: /Channel/Application/Readers#---Configuration System Chaincode (cscc) function to policy mapping for access control---## ACL policy for cscc's "GetConfigBlock" functioncscc/GetConfigBlock: /Channel/Application/Readers# ACL policy for cscc's "GetConfigTree" functioncscc/GetConfigTree: /Channel/Application/Readers# ACL policy for cscc's "SimulateConfigTreeUpdate" functioncscc/SimulateConfigTreeUpdate: /Channel/Application/Readers#---Miscellanesous peer function to policy mapping for access control---## ACL policy for invoking chaincodes on peerpeer/Propose: /Channel/Application/Writers# ACL policy for chaincode to chaincode invocationpeer/ChaincodeToChaincode: /Channel/Application/Readers#---Events resource to policy mapping for access control###---## ACL policy for sending block eventsevent/Block: /Channel/Application/Readers# ACL policy for sending filtered block eventsevent/FilteredBlock: /Channel/Application/Readers# Organizations lists the orgs participating 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: &ApplicationDefaultPoliciesReaders:Type: ImplicitMetaRule: "ANY Readers"Writers:Type: ImplicitMetaRule: "ANY Writers"Admins:Type: ImplicitMetaRule: "MAJORITY Admins"# Capabilities describes the application level capabilities, see the# dedicated Capabilities section elsewhere in this file for a full# descriptionCapabilities: <<: *ApplicationCapabilitiesApplicationDefault是Channel應用的默認配置, ACLsDefault就是配置chaincode和policy映射, 例如:
lscc和qscc都是系統默認的chaincode, 可以對應/Channel/Application/Reader或Writer
這里是Reader,Writer policy歸屬在Application當前配置范圍， 但它們又使用隱式策略ANY Readers, ANY Writers讓下一級的的子策略組去確定是否可以采訪。
Channel應用的下一級就有組織, 我們再看例子中的Profile:
# SampleDevModeSolo defines a configuration which uses the Solo orderer, # contains the sample MSP as both orderer and consortium member, and # requires only basic membership for admin privileges. It also defines # an Application on the ordering system channel, which should usually # be avoided.SampleDevModeSolo:<<: *ChannelDefaultsOrderer:<<: *OrdererDefaultsOrganizations:- <<: *SampleOrgPolicies:<<: *SampleOrgPoliciesAdmins:Type: SignatureRule: "OR('SampleOrg.member')"Application:<<: *ApplicationDefaultsOrganizations:- <<: *SampleOrgPolicies:<<: *SampleOrgPoliciesAdmins:Type: SignatureRule: "OR('SampleOrg.member')"Consortiums:SampleConsortium:Organizations:- <<: *SampleOrgPolicies:<<: *SampleOrgPoliciesAdmins:Type: Signature Rule: "OR('SampleOrg.member')"SampleDevModeSolo定義了一個區塊鏈網絡.
Application定義為Channel應用， 使用默認的ApplicationDefault配置。
包含SampleOrg一個組織, 在policy定義上有貼內容。
Policies基于SampleOrgPolicies, 并且覆寫其中的Admins policy定義, 定義為X.509證書歸屬到SampleOrg下member都可以是Admins, 這里的member應該是統配符指SampleOrg下的任意會員， 應該不是特別的OU, 也可以指定特定的OU, 例如SampleOrg.peer, SampleOrg.client, 我們之前看過一些X.509內容。
如果你看得昏昏的就對了，筆者也寫得有點暈，是不是這設計有點復雜? 當然平常這些ACL的配置我們一般很少需要去配置， 就按照configtxgen生成的默認值就好， 但是開發者需要知道Readers, Writers, Admins 策略的含義和默認的ACL的策略。
回過頭到BYFN的channel.tx更新交易報文內容, 估計就懂些了。
[root@k8s-master first-network]# configtxgen -profile TwoOrgsChannel -channelID mychannel -inspectChannelCreateTx ./channel-artifacts/channel.txread_set應該沒多大作用，主要是用于更新寫報文的write_set, 定義了groups是由Org1MSP, Org2MSP組成， 即mychannel有兩個組織會員組成，policies定義了Readers, Writers, Admins可對channel讀，寫和管理。
Readers/Writers/Admins下的ModPolicy則是指定誰才可以修改這些Readers/Writers/Amins策略內容， 這里一般都是Admins本身。
而具體的Readers,Writers權限ACL應該就是類似上面ApplicationDefaults默認對應的chaincode內容，沒顯式的打出來。
Readers,Writers對應的Signature Policy, Admins到底對應什么簽名用戶又哪里找得到呢？要暈了吧，又得回去找下創始塊的內容。
configtxgen -inspectBlock ./channel-artifacts/genesis.block創世塊json具體一些細節筆者一下也沒找到些文檔對應，講不好要跟下configtxgen源碼才能對應好，讀者有興趣也請自行跟進。
小結一下:
一個channel即一個賬本,一個鏈。
其下包含多個org組織, 組織會配置上admin, 還有OU組織單元標記用戶(config.yaml)。
一個組織可有多個接入peer節點，peer有自己的local MSP限制接入。
說白了用戶接入peer，再接入到通道，還是得依靠自身的證書的組織和OU等是否符合channel的權限配置。
如果確實需要定制化一些權限，可以在configtx.yaml組織的配置上覆寫新的policy策略。
3.chaincode的權限如何配置?
(1) 參考問題2的ApplicationDefaults ACL配置
Chaincode的安裝，實例化應該是系統級的chaincode實現的， 默認需要高級些的權限， 一般是組織Admins。
Chaincode的調用需要Writers策略
ACL policy for invoking chaincodes on peer
peer/Propose: /Channel/Application/Writers
(2) 而在鏈碼的實例化的時候是可以配置背書策略(特別是在更新操作的時候要首先要發請求到背書節點)例如需要org1和org2背書。
peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C $CHANNEL_NAME -n mycc -v 1.0 -c '{"Args":["init","a", "100", "b","200"]}' -P "AND ('Org1MSP.peer','Org2MSP.peer')"(3)使用私有數據可以配置策略, 例如
# ACL policy for invoking chaincodes on peer peer/Propose: /Channel/Application/Writers// collections_config.json[{"name": "collectionMarbles","policy": "OR('Org1MSP.member', 'Org2MSP.member')","requiredPeerCount": 0,"maxPeerCount": 3,"blockToLive":1000000},{"name": "collectionMarblePrivateDetails","policy": "OR('Org1MSP.member')","requiredPeerCount": 0,"maxPeerCount": 3,"blockToLive":3} ] peer chaincode instantiate -o orderer.example.com:7050 --tls --cafile $ORDERER_CA -C mychannel -n marblesp -v 1.0 -c '{"Args":["init"]}' -P "OR('Org1MSP.member','Org2MSP.member')" --collections-config $GOPATH/src/github.com/chaincode/marbles02_private/collections_config.json(4)鏈碼級別的背書策略設置
Chaincode/鏈碼級別的背書策略之前我們是在chaincode實例化和更新時才能修改背書策略， 而現在新的shim api接口支持在chaincode編寫的時候動態的設置背書策略。
對應shim api接口:
SetStateValidationParameter(key string, ep []byte) error GetStateValidationParameter(key string) ([]byte, error)SetPrivateDataValidationParameter(collection, key string, ep []byte) error GetPrivateDataValidationParameter(collection, key string) ([]byte, error)對應ep策略結構 type KeyEndorsementPolicy interface {// Policy returns the endorsement policy as bytesPolicy() ([]byte, error)// AddOrgs adds the specified orgs to the list of orgs that are required// to endorseAddOrgs(roleType RoleType, organizations ...string) error// DelOrgs delete the specified channel orgs from the existing key-level endorsement// policy for this KVS key. If any org is not present, an error will be returned.DelOrgs([]string) error// DelAllOrgs removes any key-level endorsement policy from this KVS key.DelAllOrgs() error// ListOrgs returns an array of channel orgs that are required to endorse changesListOrgs() ([]string, error) }最后總結下
這個進階篇可能會有其它一些遺漏，例如orderer權限， 動態調整權限等。 筆者的團隊會在實踐后再和大家分享， 有問題也歡迎大家多交流。
原文地址：https://tech.lock-in.cn/news/a74a120208ac49c0a457e54e9efed4bb
總結
以上是生活随笔為你收集整理的Hyperledger Fabric权限进阶篇的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Fabric权限管理和策略
- 下一篇： Go的json解析：Marshal与Un