Consul ACL контроль доступа

Подготовьтесь заранее

Среда: система Linux
Версия: V1.6.2
Загрузить: https://www.consul.io/downloads.html
Файл конфигурации: config-acl.json

{
    "datacenter":"tencent-datacenter",
    "data_dir":"/usr/local/consul-1.6.2/data",
    "log_file":"/usr/local/consul-1.6.2/log/",
    "log_level":"INFO",
    "bind_addr":"0.0.0.0",
    "client_addr":"0.0.0.0",
    "node_name":"tencent-node",
    "ui":true,
    "bootstrap_expect":1,
    "server":true,
    "acl":{
        "enabled":true,
        "default_policy":"deny",
        "enable_token_persistence":true,
        "enable_key_list_policy":true
    }
}

acl.enabled: включить acl
acl.default_policy: policy, deny-deny по умолчанию; allow-allow по умолчанию
acl.enable_token_persistence: разрешить постоянный токен
acl. enable_key_list_policy: Разрешить рекурсивную работу KV

Начать Консул:./consul agent -config-file=config-acl.json

Сценарии использования ACL

Контроль доступа агента
Контроль доступа к регистрации / обнаружению службы
КВ контроль доступа

Шаги по использованию ACL

Во-первых, инициализировать Consul ACL

bash: consul acl bootstrap
сгенерированная информация выглядит следующим образом (сохраните информацию):

AccessorID:       xxxx-xxxx-xxxx-xxxx-xxxx
SecretID:         xxxx-xxxx-xxxx-xxxx-xxxx
Description:      Bootstrap Token (Global Management)
Local:            false
Create Time:      2019-12-23 12:06:53.799083966 +0800 CST
Policies:
   00000000-0000-0000-0000-000000000001 - global-management

AccessorID и SecretID, сгенерированные при выполнении этой команды, имеют наивысшие права доступа.

Два, правила конфигурации

Доступ через браузер: localhost:8500введите SecretID выше во вкладке ACL, после чего вы увидите следующую страницу.
Вставьте описание изображения сюда
Политика по умолчанию: global-management, это SecretID с наивысшими полномочиями, равными суперадминистратору.

AccessorID: идентификатор доступа. Есть только один токен. Нажмите на запись, чтобы войти, и вы увидите «
Область действия:
роли и политики: есть разрешения или политики», AccessorID контролирует разрешения доступа, связывая различные роли и политики.

Вот несколько примеров политики:
1) Политика обслуживания

service_prefix "" {
    
    
  policy = "write"
}

Вышеупомянутая стратегия означает, что все службы могут быть написаны.
Ссылка на конкретную стратегию: правила службы

2) KV стратегия

key_prefix "" {
    
    
 policy = "list"
}
key_prefix "" {
    
    
 policy = "write"
}
key_prefix "config/" {
    
    
 policy = "read"
}

Первый: указывает, что все KV могут выполнять рекурсивные операции со списком.Эта опция "enable_key_list_policy":trueможет вступить в силу только после того, как будет указан файл конфигурации .
Второй: все КВ могут выполнять операции записи.
Третье: ключ, начинающийся с config /, можно прочитать.

Ссылка на конкретную стратегию: правила "ключ-значение"