Access Control Lists (ACL)¶
Что такое ACL?¶
Note: Эта тема рассматривает access control и политики канала со стороны администратора. Для информации о access control в чейнкоде, обратитесь к нашему туториалу: чейнкод для разработчиков.
Fabric использует ACL (список контроля доступа), чтобы управлять доступ к ресурсам через Политики. Fabric содержит некоторый набор стандартных ACLs. В этой статье мы разберем, в каком формате они задаются и как переопределить стандартные ACL.
Но прежде чем мы начнем, необходимо некоторое понимание ресурсов и политик.
Ресурсы¶
Пользователи взаимодействуют с Fabric, используя пользовательский чейнкод, или источник потоков событий или системный чейнкод. Эти точки управления рассматриваются как «ресурсы», которые должны подчиняться некому порядку доступа, access control.
Разработчики приложений должны знать про эти ресурсы и связанные с ними стандартные политки.
Полный список этих ресурсов находится в configtx.yaml
. Вы можете найти пример configtx.yaml
здесь.
Ресурсы, перечисленные в configtx.yaml
- полный перечень всех внутренних ресурсов, определенных в Fabric на текущий момент.
Принято перечислять их в формате <component>/<resource>
.
Так, cscc/GetConfigBlock
- это ресурс, отвечающий за вызов GetConfigBlock
компонента CSCC
.
Политики¶
Политики - один из основных элементов Fabric, так как они позволяют identity (или набору identities), сделавших запрос, быть проверенными по политикам, связанных с ресурсом, требуемом для осуществления запроса. Политики подтверждения используются, чтобы определить, была ли транзакция соответственно подтверждениа. Политики, определенные в конфигурации канала также упоминаются как политики изменения.
Политики могут быть созданы двумя способами: как политики Signature
или как политики ImplicitMeta
.
Политики Signature
¶
Политики Signature
указывают определенные типы пользователей, которые должны подписаться для удовлетворения политики.
Пример:
Policies:
MyPolicy:
Type: Signature
Rule: "OR('Org1.peer', 'Org2.peer')"
Этот код может быть истолкован так: политика с названием MyPolicy
может быть удовлетворена только подписью identity с ролью «пир организации Org1»
или «пир организации Org2».
Политики Signature
поддерживают произвольные комбинации AND
, OR
и NOutOf
,
позволяя конструировать крайне сложные правила на подобии «Администратор
организации A и два других администратора, или 11 из 20 администраторов».
Политики ImplicitMeta
¶
Политики ImplicitMeta агрегируют в себе результат политик, расположенных глубже в дереве конфигурации.
Эти политики поддерживают правила на подобии «Большинство администраторов организаций». Они используют
другой, но простой синтаксис:
<ALL|ANY|MAJORITY> <sub_policy>
.
Например: ANY
Readers
или MAJORITY
Admins
.
Заметьте, что в стандартной конфигурации политик Admins
- те, кто контролируют административные (операционные) аспекты работы сети.
Политики, указывающие, что только Admins — или подмножество Admins — имеют доступ
к ресурсу, будут, как правило, управлять важными или административными аспектами сети
(например, инстанцирование чейнкода в канале). Writers
обычно имеют права на создание proposal“ов по обновлению реестра,
но не будут иметь административные разрешения. Readers
имеют пассивную роль. Они могут только считывать информацию.
Эти стандартные политики могут быть изменены или дополнены, например, можно добавить роли peer
и client
(если
вы включили NodeOU
).
Пример политики ImplicitMeta
:
Policies:
AnotherPolicy:
Type: ImplicitMeta
Rule: "MAJORITY Admins"
В этом примере политика AnotherPolicy
может быть удовлетворена MAJORITY
(большинством) Admins
,
где Admins
будет в дальнейшем указано в более низкоуровневой политике Signature
.
Где указаны ACL?¶
Стандартные настройки контроля доступа (Access Control) находятся в configtx.yaml
, файле, который configtxgen
использует для сборки конфигурации канала.
Контроль доступа может быть обновлен двумя способами: изменением configtx.yaml
, что будет использоваться для создания конфигурации нового канала, или
обновлением контроля доступа в конфигурации существующего канала.
Как заданы ACL в configtx.yaml
¶
ACL задается как список пар ключ-значение, где ключ - это ресурс, а значение - политика доступа. Пример configtx.yaml.
Два фрагмента из этого примера:
# ACL policy for invoking chaincodes on peer (политика ACL вызова чейнкода на пирах)
peer/Propose: /Channel/Application/Writers
# ACL policy for sending block events (политика ACL для отправки событий, связанных с блоками)
event/Block: /Channel/Application/Readers
Эти ACL определяют доступ к ресурсам peer/Propose
и event/Block
: он дан только
identities, удовлетворяющим политикам с путями /Channel/Application/Writers
и /Channel/Application/Readers
соответственно.
Обновление стандартных ACL в configtx.yaml
¶
В случаях, когда необходимо переопределить стандартные ACL при создании сети или
изменить ACL до создания канала, лучше всего для этого отредактировать configtx.yaml
.
Давайте предположим, что вы хотите изменить политику ресурса peer/Propose
с
/Channel/Application/Writers
на 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: /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
Это позволит подписываться на события, связанные с блоками (block events), только SampleOrg.admin
.
Если канал уже был создан и хочет использовать это ACL, ему нужно будет обновить свою конфигурацию:
Обновление стандартных ACL существующего канала¶
Для этого потребуется совершить транзакцию конфигурации канала.
Note: Транзакции конфигурации канала вовлечены в процесс, подробно в этой статье не описанный. Для более подробной информации обратитесь к статьям Обновление конфигурации канала и Туториал «Добавление организации в канал».
После извлечения конфигурации из конфигурационного блока, отредактируйте ее, добавив
MyPolicy
в Application: policies
, где уже находятся политики Admins
, Writers
и Readers
.
"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
и role
.
К секции ACL конфига измените ACL peer/Propose
с этой строки:
"peer/Propose": {
"policy_ref": "/Channel/Application/Writers"
На эту:
"peer/Propose": {
"policy_ref": "/Channel/Application/MyPolicy"
Обратите внимание: Если в конфигурации канала отсутствовали ACL, вам придется добавить все структуру ACL.
Когда конфигурация была обновлена, потребуется утвердить ее согласно стандартному процессу обновления канала.
Удовлетворение нескольких ACL к нескольким ресурсам сразу¶
Если участник совершает запрос, включающий несколько вызовов к разным частям системного чейнкода, все связанные с этим ACL должны быть удовлетворены.
Например, peer/Propose
контролирует доступ к созданию любого proposal-запроса на канале.
Если proposal требует также доступ к двум системным чейнкодам, один из которых требует identity, удовлетворяющей Writers
, а другой - удовлетворяющей MyPolicy
,
то, когда участник выдвигает proposal, он должен иметь identity, удовлетворяющую и
Writers
, и MyPolicy
.
В стандартной конфигурации, Writers
- политика Signature
, правило которой - быть SampleOrg.member
, иными словами просто быть любым участником SampleOrg.
Правило MyPolicy
- быть администратором SampleOrg. Соответственно, чтобы удовлетворить их обеих, необходимо быть администратором SampleOrg.
Поэтому надо быть следить, чтобы ACL для proposal“ов можно было удовлетворить и чтобы ACL для propoal“а не противоречили друг другу.