Здесь https://docs.confluent.io/current/confluent-security-plugins/schema-registry/authorization/topicacl_authorizer.html здесь написано:
Список пользователей, разделенных точкой с запятой, которые могут быть суперпользователями.Нужно быть суперпользователем, чтобы выполнять все глобальные операции, которые не затрагивают такие темы, как совместимость чтения или записи.Например, admin1; admin2 сделал бы admin1 и admin2 суперпользователями.
Однако назначенный пользователь не может получить режим глобальной совместимости с Confluent Server.
Iпробовал как admin1; admin2, так и в стиле kafka Пользователь: admin1; Пользователь: admin, похоже, ничего из этого не работает.Кроме того, поскольку здесь: https://docs.confluent.io/current/confluent-security-plugins/schema-registry/install.html#authentication-mechanisms он говорит:
Механизм аутентификации для входящих запросов определяется конфигурацией confluent.schema.registry.auth.mechanism.Единственный поддерживаемый механизм в настоящее время - это SSL.
Возможно ли, чтобы пользователи имели форму "admin1" или "admin2", поскольку это не обычное различаемое имя субъекта?Не должно ли быть хотя бы что-то вроде "CN = admin1"?Поэтому я в основном пытался поставить туда:
confluent.topic.acl.super.users=CN=schema_registry,OU=IT;CN=AttunityClnt,OU=IT
и
confluent.topic.acl.super.users=User:CN=schema_registry,OU=IT;User:CN=AttunityClnt,OU=IT
, но ничего из этого не работает, сервер репликации attunity не может получить режим глобальной совместимости в обоих случаях.
Кроме того, чтобы включить подключаемый модуль безопасности реестра схемы схемы, я добавил в schema-registry.properties следующие строки:
schema.registry.resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension
confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.topicacl.SimpleTopicAclAuthorizer
inter.instance.protocol=https
ОК, поскольку я не могу понять, как определить суперпользователей для темыАвторизатор ACL, я попробовал альтернативу, то есть авторизатор ACL Registry Schema, установив для этого значение schema-registry.properties вместо предыдущего набора строк:
schema.registry.resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension
confluent.schema.registry.authorizer.class=io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizer
inter.instance.protocol=https
Я удалил настройку для confluent.topic..acl.super.users, так как я полагаю, что в этом случае это не эффективно.Я перезапустил реестр схемы, чтобы загрузить новые настройки, все началось нормально, я думаю, в соответствии с его журналами, а затем я попытался использовать sr-acl-cli, чтобы сначала определить администратора схемы, и получил это:
# bin/sr-acl-cli --config etc/schema-registry/schema-registry.properties --add -s * -p schema_registry_test -o *
Invalid operation specified : bin
Option Description
------ -----------
-h, --help Print usage information.
--add Indicates you are trying to add ACLs.
--remove Indicates you are trying to remove ACLs.
--list List all the current ACLs
--config <File> REQUIRED: Schema Registry properties file
-o, --operation <String> Operation that is being authorized. Valid operation
names are:
[SUBJECT_READ, SUBJECT_WRITE, SUBJECT_DELETE,
SUBJECT_COMPATIBILITY_READ,
SUBJECT_COMPATIBILITY_WRITE,
GLOBAL_COMPATIBILITY_READ,
GLOBAL_COMPATIBILITY_WRITE, GLOBAL_SUBJECTS_READ]
-s, --subject <String> Subject to which the ACL is being applied to. Only
applicable for SUBJECT operations. Use * to apply
to all subjects
-t, --topic <String> Topic to which the ACL is being applied to. The
corresponding subjects would topic-key and topic-
value.Only applicable for SUBJECT operations. Use
* to apply to all subjects
-p, --principal <String> Principal to which the ACL is being applied to. Use
* to apply to all principals
# cd bin
# ./sr-acl-cli --config ../etc/schema-registry/schema-registry.properties --add -s * -p schema_registry_test -o *
Invalid operation specified : confluent
Option Description
------ -----------
-h, --help Print usage information.
--add Indicates you are trying to add ACLs.
--remove Indicates you are trying to remove ACLs.
--list List all the current ACLs
--config <File> REQUIRED: Schema Registry properties file
-o, --operation <String> Operation that is being authorized. Valid operation
names are:
[SUBJECT_READ, SUBJECT_WRITE, SUBJECT_DELETE,
SUBJECT_COMPATIBILITY_READ,
SUBJECT_COMPATIBILITY_WRITE,
GLOBAL_COMPATIBILITY_READ,
GLOBAL_COMPATIBILITY_WRITE, GLOBAL_SUBJECTS_READ]
-s, --subject <String> Subject to which the ACL is being applied to. Only
applicable for SUBJECT operations. Use * to apply
to all subjects
-t, --topic <String> Topic to which the ACL is being applied to. The
corresponding subjects would topic-key and topic-
value.Only applicable for SUBJECT operations. Use
* to apply to all subjects
-p, --principal <String> Principal to which the ACL is being applied to. Use
* to apply to all principals
#
Я на самом деле хотел выполнить эту команду для пользователя CN = schema_registry, OU = IT, но результат тот же.Что мне здесь не хватает?На мгновение я подумал, что пользователи, которые не сформированы как субъектные TLS dname-s из сертификатов, могут быть полезны для доступа к реестру схемы не через https rest api, как, например, в случае sr-acl-cli, но здесь вы даетеэто конфиг в виде файла свойств реестра схемы, который в основном определяет подключение к кластеру kafka для реестра схемы.Возможно ли, что пользователь, который запускает sr-acl-cli, должен быть заранее определен как суперпользователь реестра схемы?Например, используя confluent.topic.acl.super.users ??Я тоже это попробовал, но это не помогло.Мне не ясно, как именно sr-acl-cli взаимодействует с экземпляром реестра схемы на том же компьютере, но я думаю, что пользователь, который запускает sr-acl-cli, должен быть как-то уместен, но я не знаю, как его установить.И, кстати, это работает:
sr-acl-cli --config etc/schema-registry/schema-registry.properties --list
Возвращает:
[2019-06-10 18:16:20,848] INFO Logging initialized @376ms to org.eclipse.jetty.util.log.Slf4jLog (org.eclipse.jetty.util.log:193)
[2019-06-10 18:16:20,887] INFO HV000001: Hibernate Validator 5.1.3.Final (org.hibernate.validator.internal.util.Version:27)
[2019-06-10 18:16:21,946] INFO Validating ACL topic _schemas_acl (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclAuthorizerUtils:199)
[2019-06-10 18:16:22,157] INFO Initialized last consumed offset to -1 (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclReaderThread:125)
[2019-06-10 18:16:22,200] INFO [schema-registry-acl-reader-thread]: Starting (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclReaderThread:66)
Current ACL's for Subject Operations are
{}
Current ACL's for Global Operations are
{}
[2019-06-10 18:16:22,351] INFO [schema-registry-acl-reader-thread]: Shutting down (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclReaderThread:66)
[2019-06-10 18:16:22,351] INFO [schema-registry-acl-reader-thread]: Stopped (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclReaderThread:66)
[2019-06-10 18:16:22,351] INFO [schema-registry-acl-reader-thread]: Shutdown completed (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclReaderThread:66)
[2019-06-10 18:16:22,357] INFO SchemaRegistryAclReaderThread shutdown complete. (io.confluent.kafka.schemaregistry.security.authorizer.schemaregistryacl.SchemaRegistryAclReaderThread:295)
При запуске экземпляра реестра схемы была создана новая тема _schemas_acl, так что я думаю, что по крайней мере эта часть должна бытьOK.