ロールの定義（Defining roles）

役割の定義

役割は以下のJSON構造によって定義されます:

Js

{
  "run_as": [ ... ],
  "cluster": [ ... ],
  "global": { ... },
  "indices": [ ... ],
  "applications": [ ... ],
  "remote_indices": [ ... ],
  "remote_cluster": [ ... ],
  "metadata": { ... },
  "description": "..."
}

役割名は、少なくとも1文字以上、507文字以下でなければなりません。英数字（a-z、 A-Z、 0-9）、スペース、句読点、基本ラテン（ASCII）ブロックの印刷可能な記号を含むことができます。先頭または末尾の空白は許可されていません。

インデックス権限

以下は、インデックス権限エントリの構造を説明します:

Js

{
  "names": [ ... ],
  "privileges": [ ... ],
  "field_security" : { ... },
  "query": "...",
  "allow_restricted_indices": false
}

-  ワイルドカード（デフォルト） - 簡単なワイルドカードマッチングで、`````*`````は0文字以上のプレースホルダー、`````?`````は1文字のプレースホルダー、`````\`````はエスケープ文字として使用できます。  
-  正規表現 - より複雑なパターンをマッチさせるためのより強力な構文。この正規表現はLuceneのregexpオートマトン構文に基づいています。この構文を有効にするには、スラッシュのペア（`````/`````）で囲む必要があります。`````/`````で始まり、`````/`````で終わらないパターンは不正と見なされます。
**例: 正規表現。**
#### Yaml
``````yaml
"foo-bar":               # match the literal `foo-bar`
"foo-*":                 # match anything beginning with "foo-"
"logstash-201?-*":       # ? matches any one character
"/.*-201[0-9]-.*/":      # use a regex to match anything containing 2010-2019
"/foo":                  # syntax error - missing final /
`

グローバル権限

以下は、グローバル権限エントリの構造を説明します:

Js

{
  "application": {
   "manage": {
   "applications": [ ... ]
   }
  },
  "profile": {
   "write": {
   "applications": [ ... ]
   }
  }
}

アプリケーション権限

以下は、アプリケーション権限エントリの構造を説明します:

Js

{
  "application": "my_app",
  "privileges": [ ... ],
  "resources": [ ... ]
}

これらのフィールドの検証ルールの詳細については、アプリケーション権限の追加APIを参照してください。

役割は存在しないアプリケーション権限を参照することができます。つまり、それらはまだアプリケーション権限の追加APIを通じて定義されていないか（または定義されていたが、その後削除された）ことを意味します。この場合、権限は効果がなく、権限の確認APIでのアクションを付与しません。

リモートインデックス権限

API キー ベースのモデルで構成されたリモート クラスターの場合、リモートインデックス権限を使用して、マッチするリモートクラスターのインデックス権限を指定できます。最終的な有効なインデックス権限は、リモートインデックス権限とcross-cluster API keyのインデックス権限の交差になります。

リモートインデックスは、API キー ベースのモデルで構成されたリモート クラスターに対して有効です。証明書ベースのモデルで構成されたリモート クラスターには影響しません。

リモートインデックス権限エントリには、インデックス権限エントリと比較して、追加の必須clustersフィールドがあります。それ以外は、2つの構造は同一です。以下は、リモートインデックス権限エントリの構造を説明します:

Js

{
  "clusters": [ ... ],
  "names": [ ... ],
  "privileges": [ ... ],
  "field_security" : { ... },
  "query": "...",
  "allow_restricted_indices": false
}

| | 制限されたインデックスは、設定データを内部的に保存するために使用される特別なカテゴリのインデックスであり、直接アクセスすべきではありません。
通常、内部システム役割のみが制限されたインデックスに対して権限を付与する必要があります。
このフラグを切り替えることは非常に強く推奨されません。なぜなら、重要なデータに対して無制限の操作を実質的に付与し、システム全体を不安定にしたり、機密情報を漏洩させたりする可能性があるからです。
ただし、管理目的で制限されたインデックスをカバーする権限を持つ役割を作成する必要がある場合は、このフィールドをtrueに設定する必要があります（デフォルトはfalse）、その後、namesフィールドは制限されたインデックスもカバーします。

リモートクラスター権限

API キー ベースのモデルで構成されたリモート クラスターの場合、リモートクラスター権限を使用して、マッチするリモートクラスターの追加のクラスター権限を指定できます。

リモートクラスター権限は、API キー ベースのモデルで構成されたリモート クラスターに対してのみ有効です。証明書ベースのモデルで構成されたリモート クラスターには影響しません。

以下は、リモートクラスター権限エントリの構造を説明します:

Js

{
  "clusters": [ ... ],
  "privileges": [ ... ]
}

## 例
以下のスニペットは、`````clicks_admin`````役割の定義の例を示しています:
#### Python
``````python
resp = client.security.put_role(
   name="clicks_admin",
   run_as=[
   "clicks_watcher_1"
   ],
   cluster=[
   "monitor"
   ],
   indices=[
   {
   "names": [
   "events-*"
   ],
   "privileges": [
   "read"
   ],
   "field_security": {
   "grant": [
   "category",
   "@timestamp",
   "message"
   ]
   },
   "query": "{\"match\": {\"category\": \"click\"}}"
   }
   ],
)
print(resp)
`

Js

const response = await client.security.putRole({
  name: "clicks_admin",
  run_as: ["clicks_watcher_1"],
  cluster: ["monitor"],
  indices: [
   {
   names: ["events-*"],
   privileges: ["read"],
   field_security: {
   grant: ["category", "@timestamp", "message"],
   },
   query: '{"match": {"category": "click"}}',
   },
  ],
});
console.log(response);

コンソール

POST /_security/role/clicks_admin
{
  "run_as": [ "clicks_watcher_1" ],
  "cluster": [ "monitor" ],
  "indices": [
   {
   "names": [ "events-*" ],
   "privileges": [ "read" ],
   "field_security" : {
   "grant" : [ "category", "@timestamp", "message" ]
   },
   "query": "{\"match\": {\"category\": \"click\"}}"
   }
  ]
}

上記の定義に基づいて、clicks_admin役割を持つユーザーは次のことができます:

• clicks_watcher_1ユーザーになりすまし、その代理でリクエストを実行します。
• Elasticsearchクラスターを監視します
• events-で始まるすべてのインデックスからデータを読み取ります
• これらのインデックス内では、clickカテゴリのイベントのみを読み取ります
• これらのドキュメント内では、category、@timestamp、およびmessageフィールドのみを読み取ります。

利用可能なクラスターおよびインデックス権限の完全なリストについて

役割を定義するための2つの利用可能なメカニズムがあります: 役割管理APIを使用するか、Elasticsearchノードのローカルファイルで定義することです。カスタム役割プロバイダーを実装することもできます。他のシステムと統合してユーザー役割を取得する必要がある場合は、カスタム役割プロバイダープラグインを構築できます。詳細については、役割と認可のカスタマイズを参照してください。

役割管理UI

Kibanaでユーザーと役割を簡単に管理できます。役割を管理するには、Kibanaにログインし、管理 / セキュリティ / 役割に移動します。

役割管理API

役割管理APIを使用すると、役割を動的に追加、更新、削除、および取得できます。native領域で役割を管理するためにAPIを使用すると、役割は内部のElasticsearchインデックスに保存されます。詳細と例については、役割を参照してください。

ファイルベースの役割管理

役割管理APIの他に、役割はroles.ymlファイルにローカルに定義することもできます。このファイルはES_PATH_CONFにあります。これは、各役割定義がその名前でキー付けされたYAMLファイルです。

同じ役割名がroles.ymlファイルと役割管理APIで使用されている場合、ファイル内で見つかった役割が使用されます。

役割管理APIは役割を定義するための推奨メカニズムですが、roles.ymlファイルを使用することは、管理者が物理的にElasticsearchノードにアクセスできる場合に、誰も変更できない固定役割を定義したい場合に便利です。ただし、roles.ymlファイルは最小限の管理機能として提供されており、すべてのユースケースの役割を定義するために使用されることを意図していません。

`````roles.yml`````ファイルはノードによってローカルに管理され、クラスターによってグローバルに管理されるものではありません。これは、典型的なマルチノードクラスターでは、正確に同じ変更をクラスター内のすべてのノードに適用する必要があることを意味します。  
より安全なアプローチは、ノードの1つで変更を適用し、`````roles.yml`````をクラスター内の他のすべてのノードに配布/コピーすることです（手動またはPuppetやChefなどの構成管理システムを使用して）。  
以下のスニペットは、`````roles.yml`````ファイル構成の例を示しています:
#### Yaml
``````yaml
click_admins:
  run_as: [ 'clicks_watcher_1' ]
  cluster: [ 'monitor' ]
  indices:
    - names: [ 'events-*' ]
   privileges: [ 'read' ]
   field_security:
   grant: ['category', '@timestamp', 'message' ]
   query: '{"match": {"category": "click"}}'
`

Elasticsearchはroles.ymlファイルを継続的に監視し、自動的にその変更を取得して適用します。