signature=4cf65004d6413f8de3774b51fb437988,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.com
extends:
file: peer-base.yaml
service: peer-base
environment:
- 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=Org1MSP
volumes:
- /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/production
ports:
- 7051:7051
- 7053:7053
引用到base/peer-base.yaml
services:
peer-base:
image: hyperledger/fabric-peer:$IMAGE_TAG
environment:
- 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.crt
working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
command: peer node start
peer 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
[root@k8s-master msp]# pwd
/mnt/sda3/fabric-samples/first-network/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp
[root@k8s-master msp]# ll
总用量 24
drwxr-xr-x. 2 root root 4096 9月 29 10:32 admincerts
drwxr-xr-x. 2 root root 4096 9月 29 10:32 cacerts
-rw-r--r--. 1 root root 254 9月 29 10:32 config.yaml
drwxr-xr-x. 2 root root 4096 9月 29 10:32 keystore
drwxr-xr-x. 2 root root 4096 9月 29 10:32 signcerts
drwxr-xr-x. 2 root root 4096 9月 29 10:32 tlscacerts
(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:50
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
Validity
Not Before: Sep 29 02:27:16 2018 GMT
Not After : Sep 26 02:27:16 2028 GMT
Subject: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-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:ae
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
Any Extended Key Usage
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 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:82
Signature Algorithm: ecdsa-with-SHA256
30: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才能采访当前节点。
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: cacerts/ca.org1.example.com-cert.pem
OrganizationalUnitIdentifier: client
PeerOUIdentifier:
Certificate: cacerts/ca.org1.example.com-cert.pem
OrganizationalUnitIdentifier: 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节点的私钥,可以用于数字签名。
[root@k8s-master msp]# cd keystore/
[root@k8s-master keystore]# ll
总用量 4
-rw-------. 1 root root 241 9月 29 10:32
47374918f7a4640f8d28d89b66820505702cb269bd2f1314ca420fbb64950223_sk
私钥内容
——-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:44
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
Validity
Not Before: Sep 29 02:27:16 2018 GMT
Not After : Sep 26 02:27:16 2028 GMT
Subject: C=US, ST=California, L=San Francisco, OU=peer, CN=peer0.org1.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-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:8e
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 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:82
Signature Algorithm: ecdsa-with-SHA256
30: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:64
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=tlsca.org1.example.com
Validity
Not Before: Sep 29 02:27:16 2018 GMT
Not After : Sep 26 02:27:16 2028 GMT
Subject: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=tlsca.org1.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-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:06
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
Any Extended Key Usage
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 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:4B
Signature Algorithm: ecdsa-with-SHA256
30: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:53
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=org1.example.com, CN=ca.org1.example.com
Validity
Not Before: Sep 29 02:27:16 2018 GMT
Not After : Sep 26 02:27:16 2028 GMT
Subject: C=US, ST=California, L=San Francisco, OU=client, CN=Admin@org1.example.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-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:54
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 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:82
Signature Algorithm: ecdsa-with-SHA256
30: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_NAME
Channel.tx实际是创建通道的请求报文内容,看下configtx.yaml的TwoOrgsChannel
profile对应的联盟和通道应用,包含了Org1和Org2, 即mychannel通道允许org1或org2下的用户采访。
Profiles:
TwoOrgsOrdererGenesis:
Capabilities:
<<:>
Orderer:
<<:>
Organizations:
- *OrdererOrg
Capabilities:
<<:>
Consortiums:
SampleConsortium:
Organizations:
- *Org1
- *Org2
TwoOrgsChannel:
Consortium: SampleConsortium
Application:
<<:>
Organizations:
- *Org1
- *Org2
Capabilities:
<<:>
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
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererOrg
# ID to load the MSP definition as
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
MSPDir: crypto-config/ordererOrganizations/example.com/msp
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
AnchorPeers:
# 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.com
Port: 7051
- &Org2
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org2MSP
# ID to load the MSP definition as
ID: Org2MSP
MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
AnchorPeers:
# 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.com
Port: 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下完整例子。
(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///
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')"
# 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/
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"
# Capabilities describes the channel level capabilities, see the
# dedicated Capabilities section elsewhere in this file for a full
# description
Capabilities:
<<:>
Rule语法 .
MAJORITY - 满足主要的子组的策略, 上面例子的Admins应该是下一级的signature
policy
ANY - 满足任意子组的policy
ALL - 满足所有的子组的policy
那这些POLICY怎么使用呢?通常结合ACL配置Resource的采访权限,Resource基本定义为 系统或用户的chaincode,
和系统消息资源, 我们看个例子:
Application: &ApplicationDefaults
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
# 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/
Policies: &ApplicationDefaultPolicies
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
# Capabilities describes the application level capabilities, see the
# dedicated Capabilities section elsewhere in this file for a full
# description
Capabilities:
<<:>
ApplicationDefault是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:
<<:>
Orderer:
<<:>
Organizations:
- <<:>
Policies:
<<:>
Admins:
Type: Signature
Rule: "OR('SampleOrg.member')"
Application:
<<:>
Organizations:
- <<:>
Policies:
<<:>
Admins:
Type: Signature
Rule: "OR('SampleOrg.member')"
Consortiums:
SampleConsortium:
Organizations:
- <<:>
Policies:
<<:>
Admins:
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.tx
read_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 bytes
Policy() ([]byte, error)
// AddOrgs adds the specified orgs to the list of orgs that are required
// to endorse
AddOrgs(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 changes
ListOrgs() ([]string, error)
}
最后总结下
这个进阶篇可能会有其它一些遗漏,例如orderer权限, 动态调整权限等。 笔者的团队会在实践后再和大家分享,
有问题也欢迎大家多交流。
signature=4cf65004d6413f8de3774b51fb437988,Hyperledger Fabric权限进阶篇相关推荐
- Hyperledger Fabric权限进阶篇
对于Fabric的权限和MSP配置这块,可能大家实际部署会给一堆msp目录绕晕,我们回过头来梳理一下. 1.Peer节点如何控制用户的采访权限? 我们以first-network为例, 先看下peer ...
- Hyperledger Fabric权限管理和策略
权限管理是区块链网络十分重要的功能,负责控制某个身份在某个场景下是否允许采取某个操作(如读写某个资源). 超级账本 Fabric 项目通过策略(Policy)来灵活指定各场景下的操作权限. 策略应用场 ...
- RHEL6基础四十九之RHEL文件(夹)权限进阶篇
ACL权限管理 ACL(Access Control List,访问控制列表)主要是提供传统的owner,group,others的read,write,execute权限之外的具体权限设置,ACL可 ...
- 超级账本(Hyperledger Fabric)之权限管理浅析
链客,专为开发者而生,有问必答! 此文章来自区块链技术社区,未经允许拒绝转载. 超级账本(Hyperledger Fabric)之权限管理浅析 超级账本是联盟链的代表,而其相对于共链(例如比特币,以太 ...
- 06-Docker-Centos 7.2 (Vmware最小化安装)之一篇搞定hyperledger/fabric的e2e_cli测试运行所遇到的ERROR总结
bug产生原因分析如下: 1.系统过于单纯或复杂(即最小化安装与全部安装以及自行安装了很多软件),很多命令和工具无法使用和执行或冲突 2.自己操作失误,敲错代码(关键词和语法)写错单词(一时不注意)多 ...
- Hyperledger Fabric 2.2.1 区块链问题汇总(持续更新)
搭建Hyperledger Fabric时遇到了很多问题,很多坑,这里汇总一下,有些可能没保存图片,还有些问题没及时记录起来: 1.生成orderer区块文件时,如下图所示: 必须要指定channel ...
- Hyperledger Fabric从源码分析背书提案过程
在之前的文章中 Hyperledger Fabric从源码分析链码安装过程 Hyperledger Fabric从源码分析链码实例化过程 Hyperledger Fabric从源码分析链码查询与调用 ...
- 区块链开源实现hyperledger fabric架构详解
hyperledger fabric是区块链中联盟链的优秀实现,主要代码由IBM.Intel.各大银行等贡献,目前v1.1版的kafka共识方式可达到1000/s次的吞吐量.本文中我们依次讨论:区块链 ...
- 以太坊和Hyperledger Fabric之间的差异
在这篇文章中,我们将介绍区块链中两个主要平台之间的差异:以太坊和Hyperledger.如果你正在考虑在项目中使用哪一个.这个博客的亮点是希望帮助你做出决定.但在我们详细说明之前,我们先来看一些定义. ...
最新文章
- R语言ggplot2可视化使图形的背景在不同区域有不同的颜色实战
- c++中的new与delete运算符
- Spark SQL来读取现有Hive中的数据
- 图文详解远程部署ASP.NET MVC 5项目
- Ibatis查询条件对于特殊字符的处理方法
- JVM内存溢出时快照转存HeapDump到文件
- Angular_PWA使用+Demo
- 计算机网络中seq,计算机网络A卷及参考答案
- 浪潮服务器硬盘阵列怎么做,server - 浪潮服务器RAID阵列配置及OS安装
- springboot配置文件application.properties参阅文章
- PPT双屏抽奖,大气,能Hold住全场!与其它PPT内容可融为一体,实现无缝切换!
- 西门子、三菱、台达PLC手机组态软件,支持modbus协议的ModbusTesla手机组态软件 只支持modbus tcp,只要下位机支持标准的modbus协议就可以
- Zipf,Power-laws,Pareto分布
- 芯片数据手册阅读方法
- Java中frame和panel区别,JFrame 和JPanel 的关系-区别(学习笔记)
- 基于双服务器的抗关键词猜测攻击的公钥可搜索加密方案
- Error: Too many re-renders. React limits the number of renders to prevent an infinite loop.
- 生活小技巧:PS和word的结合使用
- 32个Python爬虫项目让你一次吃到撑
- python画哆啦a梦图片_80行代码!用Python做一个哆来A梦分身
热门文章
- 用于HTML5移动开发的几大移动APP开发框架
- “京东金融”客服给你打电话,叫你注销校园贷?笔者亲身经历,绝对网络诈骗!不要相信!盘点常见的诈骗手段,与防骗方法!转载2020年网警提示的8类60种电信网络诈骗手段!
- 埃及旅游游记: 欣赏世界最古老的纸画
- 上班还想摸鱼!这个牛逼的Python模块,轻松记录键盘操作!
- HDU 6072 Logical Chain(Kosaraju+bitset)
- 方法是学习和进步的捷径
- 【MIT6.S081/6.828】手把手教你搭建开发环境
- iOS控制系统Ipod
- linux时间同步命令
- oracle报错00918,华丹学堂-Oracle报错ORA-00918: 未明确定义列原因