Spec-Zone.ru › Elasticsearch 8
›Elasticsearch Руководство [8.17] ›Настройка Elasticsearch ›Удаленные кластеры

Добавление удаленных кластеров с аутентификацией по сертификатам TLS

Для добавления удаленного кластера с использованием аутентификации по сертификатам TLS:

  1. Проверьте предварительные требования
  2. Установите доверие к удалённому кластеру
  3. Подключение к удалённому кластеру
  4. Настройка ролей и пользователей для удалённых кластеров

Если у вас возникнут проблемы, обратитесь к Устранению неполадок.

Предварительные требования

  1. Функции безопасности Elasticsearch должны быть включены на обоих кластерах, на каждом узле. Безопасность включена по умолчанию. Если она отключена, установите xpack.security.enabled в true в elasticsearch.yml. Обратитесь к разделу Общие настройки безопасности.
  2. Версии локального и удаленного кластеров должны быть совместимы.

    • Любой узел может обмениваться данными с другим узлом той же основной версии. Например, 7.0 может взаимодействовать с любым узлом 7.x.
    • Только узлы последней дополнительной версии определенной основной версии могут взаимодействовать с узлами следующей основной версии. В серии 6.x версия 6.8 может взаимодействовать с любым узлом 7.x, в то время как 6.7 может взаимодействовать только с 7.0.
    • Совместимость версий симметрична, то есть, если 6.7 может взаимодействовать с 7.0, то 7.0 также может взаимодействовать с 6.7. В следующей таблице показана совместимость версий между локальными и удаленными узлами.

      Таблица совместимости версий

      Локальный кластер

      Удаленный кластер

      5.0–5.5

      5.6

      6.0–6.6

      6.7

      6.8

      7.0

      7.1–7.16

      7.17

      8.0–8.17

      5.0–5.5

      Yes

      Yes

      No

      No

      No

      No

      No

      No

      No

      5.6

      Yes

      Yes

      Yes

      Yes

      Yes

      No

      No

      No

      No

      6.0–6.6

      No

      Yes

      Yes

      Yes

      Yes

      No

      No

      No

      No

      6.7

      No

      Yes

      Yes

      Yes

      Yes

      Yes

      No

      No

      No

      6.8

      No

      Yes

      Yes

      Yes

      Yes

      Yes

      Yes

      Yes

      No

      7.0

      No

      No

      No

      Yes

      Yes

      Yes

      Yes

      Yes

      No

      7.1–7.16

      No

      No

      No

      No

      Yes

      Yes

      Yes

      Yes

      No

      7.17

      No

      No

      No

      No

      Yes

      Yes

      Yes

      Yes

      Yes

      8.0–8.17

      No

      No

      No

      No

      No

      No

      No

      Yes

      Yes

      Elastic поддерживает межкластерный поиск только для подмножества этих конфигураций. См. Поддерживаемые конфигурации межкластерного поиска.

Установление доверия к удалённому кластеру

Для безопасного использования кросс-кластерной репликации или кросс-кластерного поиска с удалёнными кластерами включите безопасность во всех подключённых кластерах и настройте протокол Transport Layer Security (TLS) на каждом узле. Настройка TLS для транспортного интерфейса минимально необходима для удалённых кластеров. Для дополнительной безопасности настройте TLS и для интерфейса HTTP.

Все подключённые кластеры должны доверять друг другу и взаимно аутентифицироваться с помощью TLS на транспортном интерфейсе. Это означает, что локальный кластер доверяет центру сертификации (CA) удалённого кластера, а удалённый кластер — CA локального кластера. При установлении соединения все узлы будут проверять сертификаты узлов с другой стороны. Это взаимное доверие необходимо для безопасного подключения удалённого кластера, поскольку все подключённые узлы фактически образуют единую область безопасности.

Аутентификация пользователей выполняется на локальном кластере, а имена пользователя и ролей пользователя передаются в удалённые кластеры. Удалённый кластер проверяет имена ролей пользователя по своим локальным определениям ролей, чтобы определить, к каким индексам разрешен доступ пользователю.

Прежде чем использовать кросс-кластерную репликацию или кросс-кластерный поиск с защищёнными кластерами Elasticsearch, выполните следующие задачи по настройке:

  1. Настройте Transport Layer Security (TLS) на каждом узле для шифрования межузлового трафика и аутентификации узлов в локальном кластере с узлами во всех удалённых кластерах. Обратитесь к странице настройки базовой безопасности для Elastic Stack, чтобы узнать о необходимых шагах по настройке безопасности.

    В этом процессе используется один и тот же центр сертификации (CA) для генерации сертификатов для всех узлов. В качестве альтернативы можно добавить сертификаты из локального кластера в качестве доверенного центра сертификации в каждый удалённый кластер. Вы также должны добавить сертификаты из удалённых кластеров в качестве доверенного центра сертификации в локальный кластер. Использование одного центра сертификации для генерации сертификатов для всех узлов упрощает эту задачу.

Подключение к удалённому кластеру

Для подключения удалённых кластеров необходимо иметь привилегию кластера manage.

Локальный кластер использует транспортный интерфейс для установления связи с удалёнными кластерами. Координирующие узлы в локальном кластере устанавливают длительные TCP-соединения со специфическими узлами в удалённом кластере. Elasticsearch требует, чтобы эти соединения оставались открытыми, даже если они простаивают в течение длительного времени.

Для добавления удалённого кластера из Stack Management в Kibana:

  1. Выберите Удалённые кластеры из боковой навигации.
  2. Введите имя (псевдоним кластера) для удалённого кластера.
  3. Укажите URL-адрес конечной точки Elasticsearch или IP-адрес или имя хоста удалённого кластера, за которым следует порт транспортного протокола (по умолчанию 9300). Например, cluster.es.eastus2.staging.azure.foundit.no:9300 или 192.168.1.1:9300.

В качестве альтернативы используйте API обновления настроек кластера для добавления удалённого кластера. Вы также можете использовать этот API для динамической настройки удалённых кластеров для каждого узла в локальном кластере. Для настройки удалённых кластеров на отдельных узлах в локальном кластере определите статические настройки в elasticsearch.yml для каждого узла.

Следующий запрос добавляет удалённый кластер со псевдонимом cluster_one. Этот псевдоним кластера — уникальный идентификатор, представляющий соединение с удалённым кластером и используемый для различения локальных и удалённых индексов.

resp = client.cluster.put_settings(
    persistent={
        "cluster": {
            "remote": {
                "cluster_one": {
                    "seeds": [
                        "127.0.0.1:{remote-interface-default-port}"
                    ]
                }
            }
        }
    },
)
print(resp)
const response = await client.cluster.putSettings({
  persistent: {
    cluster: {
      remote: {
        cluster_one: {
          seeds: ["127.0.0.1:{remote-interface-default-port}"],
        },
      },
    },
  },
});
console.log(response);
PUT /_cluster/settings
{
  "persistent" : {
    "cluster" : {
      "remote" : {
        "cluster_one" : {    
          "seeds" : [
            "127.0.0.1:9300" 
          ]
        }
      }
    }
  }
}

Псевдоним кластера для этого удалённого кластера — cluster_one.

Указывает имя хоста и порт транспортного протокола узла-сеятеля в удалённом кластере.

Для проверки успешного подключения локального кластера к удалённому кластеру можно использовать API информации об удалённом кластере:

resp = client.cluster.remote_info()
print(resp)
response = client.cluster.remote_info
puts response
const response = await client.cluster.remoteInfo();
console.log(response);
GET /_remote/info

Ответ API показывает, что локальный кластер подключён к удалённому кластеру с псевдонимом кластера cluster_one:

{
  "cluster_one" : {
    "seeds" : [
      "127.0.0.1:9300"
    ],
    "connected" : true,
    "num_nodes_connected" : 1,  
    "max_connections_per_cluster" : 3,
    "initial_connect_timeout" : "30s",
    "skip_unavailable" : true, 
    "mode" : "sniff"
  }
}

Количество узлов в удалённом кластере, к которому подключён локальный кластер.

Указывает, следует ли пропускать удалённый кластер при поиске через кросс-кластерный поиск, если доступных узлов нет.

Динамическая настройка удалённых кластеров

Используйте API обновления настроек кластера для динамической настройки удалённых настроек на каждом узле кластера. Следующий запрос добавляет три удалённых кластера: cluster_one, cluster_two и cluster_three.

Параметр seeds указывает имя хоста и порт транспортного протокола (по умолчанию 9300) узла-сеятеля в удалённом кластере.

Параметр mode определяет конфигурируемый режим соединения, который по умолчанию равен sniff. Поскольку cluster_one не указывает mode, он использует значение по умолчанию. Как cluster_two, так и cluster_three явно используют разные режимы.

resp = client.cluster.put_settings(
    persistent={
        "cluster": {
            "remote": {
                "cluster_one": {
                    "seeds": [
                        "127.0.0.1:{remote-interface-default-port}"
                    ]
                },
                "cluster_two": {
                    "mode": "sniff",
                    "seeds": [
                        "127.0.0.1:{remote-interface-default-port-plus1}"
                    ],
                    "transport.compress": True,
                    "skip_unavailable": True
                },
                "cluster_three": {
                    "mode": "proxy",
                    "proxy_address": "127.0.0.1:{remote-interface-default-port-plus2}"
                }
            }
        }
    },
)
print(resp)
const response = await client.cluster.putSettings({
  persistent: {
    cluster: {
      remote: {
        cluster_one: {
          seeds: ["127.0.0.1:{remote-interface-default-port}"],
        },
        cluster_two: {
          mode: "sniff",
          seeds: ["127.0.0.1:{remote-interface-default-port-plus1}"],
          "transport.compress": true,
          skip_unavailable: true,
        },
        cluster_three: {
          mode: "proxy",
          proxy_address: "127.0.0.1:{remote-interface-default-port-plus2}",
        },
      },
    },
  },
});
console.log(response);
PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_one": {
          "seeds": [
            "127.0.0.1:9300"
          ]
        },
        "cluster_two": {
          "mode": "sniff",
          "seeds": [
            "127.0.0.1:9301"
          ],
          "transport.compress": true,
          "skip_unavailable": true
        },
        "cluster_three": {
          "mode": "proxy",
          "proxy_address": "127.0.0.1:9302"
        }
      }
    }
  }
}

После первоначальной конфигурации можно динамически обновить настройки для удалённого кластера. Следующий запрос обновляет настройки сжатия для cluster_two и настройки сжатия и расписания ping для cluster_three.

При изменении настроек сжатия или расписания ping все существующие соединения узлов должны быть закрыты и повторно открыты, что может привести к сбоям в выполнении запросов.

resp = client.cluster.put_settings(
    persistent={
        "cluster": {
            "remote": {
                "cluster_two": {
                    "transport.compress": False
                },
                "cluster_three": {
                    "transport.compress": True,
                    "transport.ping_schedule": "60s"
                }
            }
        }
    },
)
print(resp)
response = client.cluster.put_settings(
  body: {
    persistent: {
      cluster: {
        remote: {
          cluster_two: {
            'transport.compress' => false
          },
          cluster_three: {
            'transport.compress' => true,
            'transport.ping_schedule' => '60s'
          }
        }
      }
    }
  }
)
puts response
const response = await client.cluster.putSettings({
  persistent: {
    cluster: {
      remote: {
        cluster_two: {
          "transport.compress": false,
        },
        cluster_three: {
          "transport.compress": true,
          "transport.ping_schedule": "60s",
        },
      },
    },
  },
});
console.log(response);
PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_two": {
          "transport.compress": false
        },
        "cluster_three": {
          "transport.compress": true,
          "transport.ping_schedule": "60s"
        }
      }
    }
  }
}

Можно удалить удалённый кластер из настроек кластера, передав значения null для каждой настройки удалённого кластера. Следующий запрос удаляет cluster_two из настроек кластера, оставив cluster_one и cluster_three без изменений:

resp = client.cluster.put_settings(
    persistent={
        "cluster": {
            "remote": {
                "cluster_two": {
                    "mode": None,
                    "seeds": None,
                    "skip_unavailable": None,
                    "transport.compress": None
                }
            }
        }
    },
)
print(resp)
response = client.cluster.put_settings(
  body: {
    persistent: {
      cluster: {
        remote: {
          cluster_two: {
            mode: nil,
            seeds: nil,
            skip_unavailable: nil,
            'transport.compress' => nil
          }
        }
      }
    }
  }
)
puts response
const response = await client.cluster.putSettings({
  persistent: {
    cluster: {
      remote: {
        cluster_two: {
          mode: null,
          seeds: null,
          skip_unavailable: null,
          "transport.compress": null,
        },
      },
    },
  },
});
console.log(response);
PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "cluster_two": {
          "mode": null,
          "seeds": null,
          "skip_unavailable": null,
          "transport.compress": null
        }
      }
    }
  }
}

Статическая настройка удалённых кластеров

Если вы указываете настройки в elasticsearch.yml, только узлы с этими настройками могут подключаться к удалённому кластеру и обрабатывать запросы к удалённому кластеру.

Настройки удалённых кластеров, указанные с помощью API обновления настроек кластера, имеют приоритет над настройками, которые вы указываете в elasticsearch.yml для отдельных узлов.

В следующем примере cluster_one, cluster_two и cluster_three — произвольные псевдонимы кластеров, представляющие соединение с каждым кластером. Эти имена затем используются для различения локальных и удалённых индексов.

cluster:
    remote:
        cluster_one:
            seeds: 127.0.0.1:9300
        cluster_two:
            mode: sniff
            seeds: 127.0.0.1:9301
            transport.compress: true      
            skip_unavailable: true        
        cluster_three:
            mode: proxy
            proxy_address: 127.0.0.1:9302 

Сжатие явно включено для запросов к cluster_two.

Отключённые удалённые кластеры необязательны для cluster_two.

Адрес прокси-сервера, используемого для подключения к cluster_three.

Настройка ролей и пользователей для удалённых кластеров

После подключения удалённых кластеров, вы создаёте роль пользователя как на локальном, так и на удалённых кластерах и назначаете необходимые привилегии. Эти роли необходимы для использования кросс-кластерной репликации и кросс-кластерного поиска.

Вы должны использовать одинаковые имена ролей как на локальном, так и на удалённых кластерах. Например, в следующей конфигурации для кросс-кластерной репликации используется роль remote-replication на локальном и удалённом кластерах. Однако вы можете указывать разные определения ролей на каждом кластере.

Вы можете управлять пользователями и ролями из Stack Management в Kibana, выбрав Security > Roles в боковом меню навигации. Вы также можете использовать API для управления ролями, чтобы динамически добавлять, обновлять, удалять и получать роли. Когда вы используете API для управления ролями в native домене, роли хранятся во внутреннем индексе Elasticsearch.

В следующих запросах используется API для создания или обновления ролей. Для использования этого API вам необходима, по крайней мере, привилегия manage_security кластера.

Настройка привилегий для кросс-кластерной репликации

Пользователь кросс-кластерной репликации требует разных привилегий кластера и индекса на удалённом и локальном кластерах. Используйте следующие запросы для создания отдельных ролей на локальном и удалённом кластерах, а затем создайте пользователя с необходимыми ролями.

Удалённый кластер

На удалённом кластере, содержащем лидирующий индекс, роль кросс-кластерной репликации требует привилегию read_ccr кластера и привилегии monitor и read на лидирующем индексе.

Если запросы авторизуются с помощью ключа API, то ключ API требует указанных выше привилегий на локальном кластере, а не на удалённом.

Если запросы отправляются от имени других пользователей, тогда аутентифицируемый пользователь должен иметь привилегию run_as на удалённом кластере.

Следующий запрос создаёт роль remote-replication на удалённом кластере:

resp = client.security.put_role(
    name="remote-replication",
    cluster=[
        "read_ccr"
    ],
    indices=[
        {
            "names": [
                "leader-index-name"
            ],
            "privileges": [
                "monitor",
                "read"
            ]
        }
    ],
)
print(resp)
const response = await client.security.putRole({
  name: "remote-replication",
  cluster: ["read_ccr"],
  indices: [
    {
      names: ["leader-index-name"],
      privileges: ["monitor", "read"],
    },
  ],
});
console.log(response);
POST /_security/role/remote-replication
{
  "cluster": [
    "read_ccr"
  ],
  "indices": [
    {
      "names": [
        "leader-index-name"
      ],
      "privileges": [
        "monitor",
        "read"
      ]
    }
  ]
}
Локальный кластер

На локальном кластере, содержащем ведомый индекс, роль remote-replication требует привилегию manage_ccr кластера и привилегии monitor, read, write и manage_follow_index на ведомом индексе.

Следующий запрос создаёт роль remote-replication на локальном кластере:

resp = client.security.put_role(
    name="remote-replication",
    cluster=[
        "manage_ccr"
    ],
    indices=[
        {
            "names": [
                "follower-index-name"
            ],
            "privileges": [
                "monitor",
                "read",
                "write",
                "manage_follow_index"
            ]
        }
    ],
)
print(resp)
const response = await client.security.putRole({
  name: "remote-replication",
  cluster: ["manage_ccr"],
  indices: [
    {
      names: ["follower-index-name"],
      privileges: ["monitor", "read", "write", "manage_follow_index"],
    },
  ],
});
console.log(response);
POST /_security/role/remote-replication
{
  "cluster": [
    "manage_ccr"
  ],
  "indices": [
    {
      "names": [
        "follower-index-name"
      ],
      "privileges": [
        "monitor",
        "read",
        "write",
        "manage_follow_index"
      ]
    }
  ]
}

После создания роли remote-replication на каждом кластере, используйте API для создания или обновления пользователей, чтобы создать пользователя на локальном кластере и назначить роль remote-replication. Например, следующий запрос назначает роль remote-replication пользователю с именем cross-cluster-user:

resp = client.security.put_user(
    username="cross-cluster-user",
    password="l0ng-r4nd0m-p@ssw0rd",
    roles=[
        "remote-replication"
    ],
)
print(resp)
const response = await client.security.putUser({
  username: "cross-cluster-user",
  password: "l0ng-r4nd0m-p@ssw0rd",
  roles: ["remote-replication"],
});
console.log(response);
POST /_security/user/cross-cluster-user
{
  "password" : "l0ng-r4nd0m-p@ssw0rd",
  "roles" : [ "remote-replication" ]
}

Создавать этого пользователя нужно только на локальном кластере.

Затем вы можете настроить кросс-кластерную репликацию для репликации данных между центрами обработки данных.

Настройка привилегий для кросс-кластерного поиска

Пользователь кросс-кластерного поиска требует разные привилегии кластера и индекса на удалённом и локальном кластерах. Следующие запросы создают отдельные роли на локальном и удалённом кластерах, а затем создают пользователя с необходимыми ролями.

Удалённый кластер

На удалённом кластере роль кросс-кластерного поиска требует привилегии read и read_cross_cluster для целевых индексов.

Если запросы авторизуются с помощью ключа API, то ключ API требует указанных выше привилегий на локальном кластере, а не на удалённом.

Если запросы отправляются от имени других пользователей, тогда аутентифицируемый пользователь должен иметь привилегию run_as на удалённом кластере.

Следующий запрос создаёт роль remote-search на удалённом кластере:

resp = client.security.put_role(
    name="remote-search",
    indices=[
        {
            "names": [
                "target-indices"
            ],
            "privileges": [
                "read",
                "read_cross_cluster"
            ]
        }
    ],
)
print(resp)
const response = await client.security.putRole({
  name: "remote-search",
  indices: [
    {
      names: ["target-indices"],
      privileges: ["read", "read_cross_cluster"],
    },
  ],
});
console.log(response);
POST /_security/role/remote-search
{
  "indices": [
    {
      "names": [
        "target-indices"
      ],
      "privileges": [
        "read",
        "read_cross_cluster"
      ]
    }
  ]
}
Локальный кластер

На локальном кластере, который используется для инициирования кросс-кластерного поиска, пользователю нужна только роль remote-search. Привилегии роли могут быть пустыми.

Следующий запрос создаёт роль remote-search на локальном кластере:

resp = client.security.put_role(
    name="remote-search",
)
print(resp)
const response = await client.security.putRole({
  name: "remote-search",
});
console.log(response);
POST /_security/role/remote-search
{}

После создания роли remote-search на каждом кластере, используйте API для создания или обновления пользователей, чтобы создать пользователя на локальном кластере и назначить роль remote-search. Например, следующий запрос назначает роль remote-search пользователю с именем cross-search-user:

resp = client.security.put_user(
    username="cross-search-user",
    password="l0ng-r4nd0m-p@ssw0rd",
    roles=[
        "remote-search"
    ],
)
print(resp)
const response = await client.security.putUser({
  username: "cross-search-user",
  password: "l0ng-r4nd0m-p@ssw0rd",
  roles: ["remote-search"],
});
console.log(response);
POST /_security/user/cross-search-user
{
  "password" : "l0ng-r4nd0m-p@ssw0rd",
  "roles" : [ "remote-search" ]
}

Создавать этого пользователя нужно только на локальном кластере.

Пользователи с ролью remote-search могут затем выполнять поиск по нескольким кластерам.

Настройка привилегий для поиска по нескольким кластерам и Kibana

При использовании Kibana для поиска в нескольких кластерах процесс авторизации происходит в два этапа, определяющих возможность доступа пользователя к потокам данных и индексам удаленного кластера:

  • Сначала локальный кластер определяет, авторизован ли пользователь для доступа к удаленным кластерам. Локальный кластер — это кластер, к которому подключена Kibana.
  • Если пользователь авторизован, удаленный кластер определяет, имеет ли пользователь доступ к указанным потокам данных и индексам.

Для предоставления пользователям Kibana доступа к удаленным кластерам назначьте им локальную роль с правами чтения на индексы в удаленных кластерах. Потоки данных и индексы в удаленном кластере указываются в виде <remote_cluster_name>:<target>.

Для предоставления пользователям прав на чтение удаленных потоков данных и индексов необходимо создать соответствующую роль в удаленных кластерах, предоставляющую read_cross_cluster право доступа к нужным потокам данных и индексам.

Например, вы можете активно индексировать данные Logstash в локальном кластере и периодически перемещать более старые индексы на основе времени в архив на удаленном кластере. Для поиска по обоим кластерам необходимо включить пользователей Kibana в обоих кластерах.

Локальный кластер

В локальном кластере создайте роль logstash-reader, которая предоставляет read и view_index_metadata права на локальные индексы logstash-*.

Если вы настраиваете локальный кластер как еще один удаленный в Elasticsearch, роль logstash-reader в локальном кластере также должна предоставлять право read_cross_cluster.

resp = client.security.put_role(
    name="logstash-reader",
    indices=[
        {
            "names": [
                "logstash-*"
            ],
            "privileges": [
                "read",
                "view_index_metadata"
            ]
        }
    ],
)
print(resp)
const response = await client.security.putRole({
  name: "logstash-reader",
  indices: [
    {
      names: ["logstash-*"],
      privileges: ["read", "view_index_metadata"],
    },
  ],
});
console.log(response);
POST /_security/role/logstash-reader
{
  "indices": [
    {
      "names": [
        "logstash-*"
        ],
        "privileges": [
          "read",
          "view_index_metadata"
          ]
    }
  ]
}

Назначьте пользователям Kibana роль, предоставляющую доступ к Kibana, а также вашу роль logstash_reader. Например, следующий запрос создает пользователя cross-cluster-kibana и назначает роли kibana-access и logstash-reader.

resp = client.security.put_user(
    username="cross-cluster-kibana",
    password="l0ng-r4nd0m-p@ssw0rd",
    roles=[
        "logstash-reader",
        "kibana-access"
    ],
)
print(resp)
const response = await client.security.putUser({
  username: "cross-cluster-kibana",
  password: "l0ng-r4nd0m-p@ssw0rd",
  roles: ["logstash-reader", "kibana-access"],
});
console.log(response);
PUT /_security/user/cross-cluster-kibana
{
  "password" : "l0ng-r4nd0m-p@ssw0rd",
  "roles" : [
    "logstash-reader",
    "kibana-access"
    ]
}
Удаленный кластер

В удаленном кластере создайте роль logstash-reader, которая предоставляет право read_cross_cluster, а также права read и view_index_metadata для индексов logstash-*.

resp = client.security.put_role(
    name="logstash-reader",
    indices=[
        {
            "names": [
                "logstash-*"
            ],
            "privileges": [
                "read_cross_cluster",
                "read",
                "view_index_metadata"
            ]
        }
    ],
)
print(resp)
const response = await client.security.putRole({
  name: "logstash-reader",
  indices: [
    {
      names: ["logstash-*"],
      privileges: ["read_cross_cluster", "read", "view_index_metadata"],
    },
  ],
});
console.log(response);
POST /_security/role/logstash-reader
{
  "indices": [
    {
      "names": [
        "logstash-*"
        ],
        "privileges": [
          "read_cross_cluster",
          "read",
          "view_index_metadata"
          ]
    }
  ]
}

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/8.17/remote-clusters-cert.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API