Как ограничить доступ к «обновлению одноранговой сети» для конкретной организации

Question

Можно ли ограничить команду «peer chaincode upgrade» конкретной организацией? Мне бы хотелось, чтобы одна организация работала в качестве «специалиста по техническому обслуживанию» для всей сети.

Я настраиваю сеть Hyperledger Fabric 1.4.3 с тремя организациями: Org1, Org2, Org3. Сеть использует один канал и несколько коллекций личных данных для обмена конфиденциальными данными между организациями. Я хотел бы добавить четвертую организацию к работающей сети. Я знаю, как создать необходимый криптографический материал, вызвать дополнительные контейнеры Docker, присоединиться к каналу и установить цепной код. Однако, добавляя четвертую организацию, требуются дополнительные коллекции личных данных, которые должны быть указаны в команде 'peer channel upgrade' с помощью параметра --collections-config. На данный момент все работает отлично. Я использую CLI Peer0 из Org1 для выдачи всех команд 'peer chaincode ...'. Однако я хотел бы ограничить доступ к этой функции для какой-либо другой организации, например: только администратор из Org3 может выполнить «обновление однорангового кодового кода». Я попытался изменить раздел «Каналы / Политики / Администраторы» файла configtx.yaml на:

Type: Signature
Rule: "OR('Org3MSP.admin')"

, но я все еще могу выполнить обновление «peer chaincode» из CLI Peer0.Org1.

Приложениераздел моего configtx.yaml:

Application: &ApplicationDefaults
    Organizations:
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "MAJORITY Admins"
        Org1MemberPolicy:
            Type: Signature
            Rule: "OR('Org1MSP.member')"
        Org2MemberPolicy:
            Type: Signature
            Rule: "OR('Org2MSP.member')"
        Org3MemberPolicy:
            Type: Signature
            Rule: "OR('Org3MSP.member')"
    Capabilities:
        <<: *ApplicationCapabilities

раздел канала моего configtx.yaml:

Channel: &ChannelDefaults
    Policies:
        Readers:
            Type: ImplicitMeta
            Rule: "ANY Readers"
        Writers:
            Type: ImplicitMeta
            Rule: "ANY Writers"
        Admins:
            Type: ImplicitMeta
            Rule: "ANY Admins"
    Capabilities:
        <<: *ChannelCapabilities

раздел Profiles моего configtx.yaml:

Profiles:
    ThreeOrgsOrdererGenesis:
        <<: *ChannelDefaults
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
                    - *Org3
    Orgs123Channel:
        <<: *ChannelDefaults
        Consortium: SampleConsortium
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
                - *Org3
            Capabilities:
                <<: *ApplicationCapabilities

Я предполагаю, что это настраивается где-то в configtx.yaml, но я не могу понять, где именно.

Answer 1

Контроль доступа для создания или обновления цепного кода осуществляется с помощью политик создания. Политики создания экземпляров определяются как часть пакета кода цепи с использованием параметра -i:

peer chaincode package -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/example02/cmd -v 0 -s -S -i "AND('OrgA.admin')" ccpack.out

В Fabric v2.x и более поздних версиях (будет выпущен в ближайшее время) новая модель жизненного цикла цепного кода обеспечивает гораздо лучший контроль над этим, так какхорошо.