Amazon OpenSearch 服務中的精細訪問控制 - Amazon OpenSearch Service

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Amazon OpenSearch 服務中的精細訪問控制

精細的存取控制提供了控制 Amazon OpenSearch 服務上資料存取的其他方式。例如,根據提出請求的人員,您可能會希望搜尋只傳回一個索引的結果。您可能會希望隱藏文件中的某些欄位,或是排除特定的文件。

精細存取控制具有以下優勢:

  • 角色類型存取控制

  • 索引、文件和欄位層級的安全

  • OpenSearch 多租戶儀表板

  • OpenSearch 和 OpenSearch 儀表板的 HTTP 基本驗證

更大的局面:精細的訪問控制和 OpenSearch 服務安全

Amazon OpenSearch 服務安全有三個主要層面:

網路

第一個安全層是網路,它決定要求是否到達 OpenSearch Service 網域。如果您在建立網域時選擇 Public access (公有存取),則來自任何網際網路連線用戶端的請求都能連線到網域端點。如果您選擇 VPC access (VPC 存取),用戶端必須連線至 VPC (且相關聯的安全群組也必須允許),請求才能連線到端點。如需詳細資訊,請參閱 在 中啟動 Amazon OpenSearch Service 網域 VPC

網域存取政策

第二個安全層次是網域存取政策。在請求連線到網域端點後,資源類型存取政策會允許或拒絕對指定 URI 的請求存取。存取原則會在網域的「邊緣」處接受或拒絕要求,然後再到達 OpenSearch本身。

精細定義存取控制

第三個和最後一個安全層次是精細存取控制。在資源類型存取政策允許請求連線到網域端點後,精細存取控制會評估使用者登入資料,並讓使用者通過身分驗證或拒絕請求。如果精細存取控制讓使用者通過身分驗證,則會擷取所有映射到該使用者的角色,並使用完整的許可集合來判斷如何處理請求。

注意

如果以資源為基礎的存取政策包含 IAM 角色或使用者,用戶端必須使用簽 AWS 名版本 4 傳送已簽署的請求。因此,存取政策可能會和精細存取控制產生衝突,特別是當您使用內部使用者資料庫和 HTTP 基本身分驗證時。您無法使用使用者名稱和密碼以 IAM 登入資料來簽署請求。一般而言,如果您啟用了精細存取控制,我們建議您使用不需要簽章請求的網域存取政策。

下圖說明了常見的組態:啟用精細存取控制的 VPC 存取網域、IAM 型的存取政策以及 IAM 主要使用者。

具備 VPC 網域的精細存取控制授權流程

下圖說明了另一種常見的組態:啟用精細存取控制的公有存取網域,不使用 IAM 委託人的存取政策,以及內部使用者資料庫中的主要使用者。

具備公有存取網域的精細存取控制授權流程

範例

假設有一個對 movies/_search?q=thor 提出的 GET 請求。使用者具備搜尋 movies 索引的許可嗎? 如果具備的話,使用者是否具備查看其中所有文件的許可? 回應應該要省略或匿名化任何欄位嗎? 針對主要使用者,回應看起來可能如下:

{ "hits": { "total": 7, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "directors": [ "Kenneth Branagh", "Joss Whedon" ], "release_date": "2011-04-21T00:00:00Z", "genres": [ "Action", "Adventure", "Fantasy" ], "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor", "actors": [ "Chris Hemsworth", "Anthony Hopkins", "Natalie Portman" ], "year": 2011 } }, ... ] } }

如果具備受限性較高許可的使用者提出了完全相同的請求,則回應看起來可能會如下:

{ "hits": { "total": 2, "max_score": 8.772789, "hits": [{ "_index": "movies", "_type": "_doc", "_id": "tt0800369", "_score": 8.772789, "_source": { "year": 2011, "release_date": "3812a72c6dd23eef3c750c2d99e205cbd260389461e19d610406847397ecb357", "plot": "The powerful but arrogant god Thor is cast out of Asgard to live amongst humans in Midgard (Earth), where he soon becomes one of their finest defenders.", "title": "Thor" } }, ... ] } }

回應的命中數會較少,且每個命中的欄位數也會比較少。此外,release_date 欄位會進行匿名化。如果沒有具備任何許可的使用者提出相同的請求,則叢集會傳回錯誤:

{ "error": { "root_cause": [{ "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }], "type": "security_exception", "reason": "no permissions for [indices:data/read/search] and User [name=limited-user, roles=[], requestedTenant=null]" }, "status": 403 }

如果使用者提供了無效的登入資料,則叢集會傳回 Unauthorized 例外狀況。

重要概念

當您開始使用精細的存取控制時,請考慮下列概念:

  • 角色 — 使用精細存取控制的核心方式。在這種情況下,角色與 IAM 角色不同。角色包含了任何許可的組合:全叢集、特定索引、文件層級,以及欄位層級。

  • 映射」— 配置角色后,您可以將其射到一個或多個用戶。例如,您可以將三個角色映射到單一使用者:其中一個角色提供存取給 Dashboards,第二個角色提供唯讀存取給 index1,第三個角色則提供寫入存取給 index2。或者,您可以在單一角色中包含這些許可。

  • 使用者 — 對 OpenSearch 叢集發出要求的人員或應用程式。使用者擁有在提出請求時指定的登入資料 (IAM 存取金鑰或使用者名稱和密碼)。

關於主要使用者

OpenSearch 服務中的主要使用者可以是使用者名稱和密碼組合,或是 IAM 主體,具有基礎 OpenSearch叢集的完整許可。如果使用者具有 OpenSearch 叢集的所有存取權,並且能夠在 OpenSearch 儀表板中建立內部使用者、角色和角色對應,則該使用者將被視為主要使用者。

在 OpenSearch Service 主控台或透過 CLI 建立的主要使用者會自動對應至兩個預先定義的角色:

  • all_access— 提供對所有叢集範圍作業的完整存取權、寫入所有叢集索引的權限,以及寫入所有租用戶的權限。

  • security_manager— 提供對安全插件的訪問以及對用戶和權限的管理。

透過這兩個角色,使用者可以存取 OpenSearch 儀表板中的 [安全性] 索引標籤,在此他們可以管理使用者和權限。如果您建立另一個內部使用者,並且僅將其對應至all_access角色,則該使用者無法存取 [安全性] 索引標籤。您可以透過將主要使用者明確對應至all_accesssecurity_manager角色來建立其他主要使用者。如需說明,請參閱其他主要使用者

當您為網域建立主要使用者時,可以指定現有的 IAM 主體,或在內部使用者資料庫中建立主要使用者。決定要使用哪一個時,請考慮下列事項:

  • IAM 主體 — 如果您為主要使用者選擇 IAM 主體,則對叢集的所有請求都必須使用 AWS 簽名版本 4 簽署。

    OpenSearch 服務不會考慮任何 IAM 主體的許可。IAM 使用者或角色純粹用於驗證。該使用者或角色的策略與主要使用者的授權無關。授權是透過 OpenSearch 安全性外掛程式中的各種權限來處理。

    例如,您可以為 IAM 主體指派零 IAM 許可,而且只要機器或人員可以向該使用者或角色進行驗證,他們就可以在 OpenSearch 服務中擁有主要使用者的能力。

    如果您想要在多個叢集上使用相同的使用者、想要使用 Amazon Cognito 存取儀表板,或者您的用 OpenSearch 戶端支援簽名版本 4 簽署,我們建議您使用 IAM。

  • 內部使用者資料庫 — 如果您在內部使用者資料庫中建立 master (使用者名稱和密碼組合),則可以使用 HTTP 基本身份驗證 (以及 IAM 登入資料) 向叢集發出請求。大多數客戶端支持基本身份驗證,包括 curl,它還支持帶有 ---aw s-sigv4 選項的 AWS 簽名版本 4。內部使用者資料庫儲存在 OpenSearch 索引中,因此您無法與其他叢集共用。

    如果您不需要跨多個叢集重複使用使用者、希望使用 HTTP 基本身分驗證來存取 Dashboards (而非 Amazon Cognito),或是您具備只支援基本身分驗證的用戶端,則我們建議您使用內部使用者資料庫。內部使用者資料庫是開始使用 OpenSearch Service 的最簡單方式。

啟用精細存取控制

使用主控台或設定 API 啟用精細的存取控制。 AWS CLI如需這些步驟,請參閱 建立和管理 Amazon OpenSearch Service 網域

精細的訪問控制需要 OpenSearch 或彈性搜索 6.7 或更高版本。它還需要 HTTPS 才能進入域的所有流量,靜態數據node-to-node 加密和加密。視您設定精細存取控制進階功能的方式而定,對要求進行額外處理可能需要個別資料節點上的運算和記憶體資源。在您啟用精細存取控制後,您便無法停用此功能。

在現有網域上啟用精細存取控制

您可以對執行中的現有網域 OpenSearch 或 Elasticsearch 6.7 或更新版本啟用精細的存取控制。

在現有網域上啟用精細存取控制 (主控台)
  1. 選取網域,並選擇 Actions (動作) 和 Edit security configuration (編輯安全組態)。

  2. 選取 Enable fine-grained access control (啟用精細存取控制)。

  3. 選擇建立主要使用者的方法:

    • 如果您希望使用 IAM 進行使用者管理,請選擇 Set IAM ARN as master user (將 IAM ARN 設為主要使用者),並指定 IAM 角色的 ARN。

    • 如果您要使用內部使用者資料庫,請選擇 [建立主要使用者],然後指定使用者名稱和密碼。

  4. (選用) 選取 Enable migration period for open/IP-based access policy (啟用開放/IP 型存取政策的遷移期)。此設定會啟用 30 天的過渡期,在此期間,您目前的使用者可繼續存取網域,不會中斷,且現有的開放和 IP 型存取政策仍可繼續使用您的網域。在此遷移期間,我們建議管理員為網域建立必要角色,並將其映射至使用者。如果您使用以身分為基礎的政策,而非開放或 IP 型存取政策,則您可以停用此設定。

    您也需要更新客户端,以在遷移期間使用精細存取控制。例如,如果您使用精細的存取控制對應 IAM 角色,則必須更新用戶端以開始使用簽 AWS 名版本 4 簽署請求。如果您使用精細存取控制設定 HTTP 基本身分驗證,則必須更新客户端,以在請求中提供適當的基本身分驗證憑證。

    在移轉期間,存取網域之 OpenSearch 儀表板端點的使用者將直接登入「索」頁面,而不是登入頁面。管理員和主要使用者可選擇 Login (登入),使用管理員憑據登入並設定角色映射。

    重要

    OpenSearch 服務會在 30 天後自動停用遷移期間。我們建議您在建立必要角色並將其映射至使用者後,立即結束該角色。遷移期結束後,您便無法重新啟用。

  5. 選擇儲存變更

在叢集運作狀態變成紅色期間,變更會觸發藍/綠部署,但所有叢集操作皆不受影響。

在現有網域上啟用精細存取控制 (CLI)

AnonymousAuthEnabled 設定為 true,以使用精細存取控制來啟用遷移期:

aws opensearch update-domain-config --domain-name test-domain --region us-east-1 \ --advanced-security-options '{ "Enabled": true, "InternalUserDatabaseEnabled":true, "MasterUserOptions": {"MasterUserName":"master-username","MasterUserPassword":"master-password"},"AnonymousAuthEnabled": true}'

關於 default_role

精細存取控制需要角色映射。如果您的網域使用以身分識別為基礎的存取原則, OpenSearch Service 會自動將您的使用者對應至名為 default_role 的新角色,以協助您正確移轉現有使用者。在您建立自有角色映射之前,此臨時映射可確保您的使用者仍可成功傳送由 IAM 簽署之 GET 和 PUT 請求。

此角色不會在您的 OpenSearch Service 網域中新增任何安全性弱點或瑕疵。我們建議您在設定自有角色後並相應映射它們後,立即刪除預設角色。

遷移案例

下表說明在現有網域上啟用精細存取控制前後的各身分驗證方法的行為,以及若管理員要將其使用者正確映射至角色,必須採取的步驟:

身分驗證方法 在啟用精細存取控制前 在啟用精細存取控制後 管理員任務
以身分為基礎的政策

滿足 IAM 政策的所有使用者都可以存取該網域。

您無需啟用遷移期。

OpenSearch 服務會自動將符合 IAM 政策的所有使用者對應到 default_role,以便他們可以繼續存取網域。

  1. 在網域上建立自訂角色映射。

  2. 刪除 default_role

以 IP 為基礎的政策

來自受允許 IP 地址或 CIDR 區塊的所有使用者皆可存取網域。

在 30 天遷移期內,所有來自受允許 IP 地址或 CIDR 區塊的使用者都可繼續存取網域。

  1. 在網域上建立自訂角色映射。

  2. 依據您的角色映射組態,更新您的客户端以提供基本身分驗證憑證或 IAM 憑證。

  3. 停用遷移期。若來自受允許的 IP 地址或 CIDR 區塊的使用者,在沒有基本身分驗證或 IAM 憑證的情況下傳送請求,將失去網域的存取權限。

開放存取政策

網際網路上的所有使用者皆可存取網域。

在 30 天的遷移期內,網際網路上的所有使用者皆可繼續存取網域。

  1. 在網域上建立角色映射

  2. 依據您的角色映射組態,更新您的客户端以提供基本身分驗證憑證或 IAM 憑證。

  3. 停用遷移期。使用者在沒有基本身分驗證或 IAM 憑證的情況下傳送請求,將失去網域的存取權限。

以主要使用者身分存取 OpenSearch 儀表板

精細的存取控制具有可簡化管理工作的 OpenSearch 儀表板外掛程式。您可以使用 Dashboards 來管理使用者、角色、映射、動作群組和租用戶。但是, OpenSearch 儀表板登入頁面和基礎驗證方法會有所不同,視您管理使用者和設定網域的方式而定。

管理許可

重要概念 中所述,您可以使用角色、使用者和映射來管理精細存取控制許可。本節說明如何建立和套用這些資源。我們建議您以主要使用者身分登入 Dashboards,以執行這些操作。

Dashboards 中的安全首頁
注意

您選擇授予使用者的許可,根據使用案例有很大差異。我們無法在本文中涵蓋所有案例。當您決定要授與使用者的權限時,請務必參考下列各節中提到的 OpenSearch 叢集和索引權限,並始終遵循最低權限原則

建立角色

您可以使用 OpenSearch 儀表板或 REST API 中的_plugins/_security操作來建立新角色,以進行精細的存取控制。如需詳細資訊,請參閱建立角色

精細存取控制也包含了許多預先定義角色。 OpenSearch 儀表板和 Logstash 等用戶端會向各種各樣的要求發出 OpenSearch,這可能會讓您難以手動建立具有最低權限集的角色。例如,opensearch_dashboards_user 角色包含了使用者使用索引模式、視覺化及儀表板和租用戶所需要的許可。我們建議將其映射至存取 Dashboards 的任何使用者或後端角色,以及允許存取其他索引的其他角色。

Amazon OpenSearch 服務不提供以下 OpenSearch 角色:

  • observability_full_access

  • observability_read_access

  • reports_read_access

  • reports_full_access

Amazon OpenSearch 服務提供了幾個角色,這些角色不適用於 OpenSearch:

  • ultrawarm_manager

  • ml_full_access

  • cold_manager

  • notifications_full_access

  • notifications_read_access

叢集層級安全

叢集層級許可包括能夠發出廣泛請求 (例如 _mget_msearch 以及 _bulk)、監控運作狀態、擷取快照等。請在建立角色時使用 Cluster Permissions (叢集許可) 部分來管理這些許可。如需完整的叢集層級許可清單,請參閱叢集許可

您通常可以使用預設動作群組組合,而不是個別許可,達到所需的安全狀態。如需叢集層級動作群組的清單,請參閱叢集層級

索引層級安全

索引層級許可包含建立新索引、搜尋索引、讀取和寫入文件、刪除文件、管理別名等能力。請在建立角色時使用 Index Permissions (索引許可) 部分來管理這些許可。如需完整的索引層級許可清單,請參閱索引許可

您通常可以使用預設動作群組組合,而不是個別許可,達到所需的安全狀態。如需索引層級動作群組的清單,請參閱索引層級

文件層級安全

文件層級安全可讓您限制使用者在索引中可看見的文件。建立角色時,請指定索引模式和 OpenSearch 查詢。任何您映射到該角色的使用者都只能看見與查詢相符的文件。文件層級安全會影響您在搜尋時的命中數

如需詳細資訊,請參閱文件層級安全

欄位層級安全

欄位層級安全可讓您控制使用者能看見的文件欄位。建立角色時,請新增欄位清單來加入或排除。如果您加入欄位,則您映射到該角色的任何使用者都只能看到那些欄位。如果您排除欄位,則「除了」遭排除的欄位外,使用者可以看見所有欄位。欄位層級安全會影響您在搜尋時包含在命中中的欄位數

如需詳細資訊,請參閱欄位層級安全

欄位遮罩

欄位遮罩是欄位層級安全的替代項目,可讓您匿名化欄位中的資料,而非完全移除。請在建立角色時,新增要進行遮罩的欄位清單。欄位遮罩會影響您在搜尋時是否可以看見欄位的內容

提示

如果您將標準遮罩套用至欄位, OpenSearch Service 會使用安全的隨機雜湊,這可能會造成不正確的彙總結果。若要在遮罩欄位上執行彙總,請改用以模式為基礎的遮罩。

建立 使用者

如果您啟用了內部使用者資料庫,則可以使用 OpenSearch儀表板或 REST API 中的_plugins/_security作業來建立使用者。如需詳細資訊,請參閱建立使用者

如果您為主要使用者選擇了 IAM,請忽略 Dashboards 的這個部分。請改為建立 IAM 角色。如需詳細資訊,請參閱《IAM 使用者指南》https://docs.aws.amazon.com/IAM/latest/UserGuide/

將角色映射至使用者

角色映射是精細存取控制中最重要的層面。精細存取控制包含了一些預先定義角色,可協助您開始使用,但除非您將這些角色映射到使用者,否則每個向叢集提出的請求都會導致許可錯誤。

後端角色有助於簡化角色對應程序。您可以將角色對應至所有 100 位使用者共用的單一後端角色,而不是將相同角色對應至 100 位個別使用者。後端角色可以是 IAM 角色或任意字串。

  • Users (使用者) 區段中指定使用者、使用者 ARN 和 Amazon Cognito 使用者字串。Cognito 使用者字串的形式為 Cognito/user-pool-id/username

  • 請在 Backend roles (後端角色) 區段中指定後端角色和 IAM 角色 ARN。

角色映射畫面

您可以使用 OpenSearch 儀表板或 REST API 中的_plugins/_security作業將角色對應至使用者。如需詳細資訊,請參閱將使用者映射至角色

建立動作群組

動作群組是一組許可,可讓您跨不同資源重複使用。您可以使用 OpenSearch 儀表板或 REST API 中的_plugins/_security操作來建立新的動作群組,但預設動作群組已足以滿足大多數使用案例的需求。如需預設動作群組的詳細資訊,請參閱預設動作群組

OpenSearch 多租戶儀表板

租用戶是儲存索引模式、視覺化、儀表板和其他 Dashboards 物件的空間。多租戶儀表板可讓您與其他儀表板使用者安全地共用您的工作 (或將其保持私密),並動態設定租用戶。您可以控制哪些角色可以存取租用戶,以及這些角色是否具備讀取或寫入存取權限。全域租用戶為預設值。若要深入了解,請參閱多租戶OpenSearch 儀表板

檢視您目前的租用戶或變更租用戶
  1. 導覽至「 OpenSearch 儀表板」並登入。

  2. 選取右上角的使用者圖示,然後選擇 Switch tenants (轉換租用戶)。

  3. 在建立視覺效果或儀表板之前驗證您的租用戶。如果您希望與其他所有的 Dashboards 使用者共享您的作品,請選擇 Global (全域)。若要與一部分 Dashboards 使用者共享您的作品,請選擇不同的共享租用戶。否則,請選擇 Private (私有)

注意

OpenSearch 儀表板會為每個承租人維護個別的索引,並建立名為的索引範本tenant_template。請勿刪除或修改tenant_template索引,因為如果租用戶索引對應設定錯誤,可能會導致 OpenSearch 儀表板發生錯誤。

建議的組態

由於精細存取控制與其他安全功能的互動方式,我們建議使用數種精細存取控制組態。這些組態適合大多數的使用案例。

描述 主要使用者 網域存取政策

使用 IAM 登入資料呼叫 OpenSearch API,並使用 SAML 身份驗證來存取儀表板。使用 Dashboards 或 REST API 管理精細存取控制角色。

IAM 角色或使用者
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

使用 IAM 登入資料或基本身份驗證來呼叫 OpenSearch API。使用 Dashboards 或 REST API 管理精細存取控制角色。

此配置提供了很多靈活性,特別是如果您的 OpenSearch客戶端只支持基本身份驗證。

如果您擁有現有的身分提供者,請使用 SAML 身分驗證來存取 Dashboards。否則,請管理內部使用者資料庫中的 Dashboards 使用者。

用戶名和密碼
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

使用 IAM 登入資料來呼叫 OpenSearch API,並使用 Amazon Cognito 存取儀表板。使用 Dashboards 或 REST API 管理精細存取控制角色。

IAM 角色或使用者
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" } ] }

使用 IAM 登入資料呼叫 OpenSearch API,並封鎖對儀表板的大多數存取權。使用 REST API 管理精細存取控制角色。

IAM 角色或使用者
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/*" }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": "es:ESHttp*", "Resource": "domain-arn/_dashboards*" } ] }

限制

精細存取控制有幾個重要的限制:

  • 如果網域是位於 VPC 中,則將角色映射到主機名稱或 IP 地址的角色映射 hosts 層面會無法正常運作。您仍然可以將角色映射到使用者和後端角色。

  • 如果您為主要使用者選擇了 IAM 但並未啟用 Amazon Cognito 或 SAML 身分驗證,則 Dashboards 會顯示沒有任何功能的登入頁面。

  • 如果您為主要使用者選擇了 IAM,您仍然可以在內部使用者資料庫中建立使用者。但是,由於沒有在這個組態下啟用 HTTP 基本身分驗證,因此任何使用這些使用者登入資料簽署的請求都會遭到拒絕。

  • 如果您使用 SQL 來查詢您無法存取的索引,便會收到「沒有許可」錯誤。如果索引不存在,則您會收到「找不到索引」錯誤。這項錯誤訊息中的差異表示如果您猜測其名稱,您便可以確認該索引是否存在。

    為了將問題降至最低,請不要在索引名稱中包含敏感資訊。如要拒絕所有對 SQL 的存取,請將以下元素新增到您的網域存取政策:

    { "Effect": "Deny", "Principal": { "AWS": [ "*" ] }, "Action": [ "es:*" ], "Resource": "arn:aws:es:us-east-1:123456789012:domain/my-domain/_plugins/_sql" }
  • 如果您的網域版本為 2.3 或更高版本,且啟用了精細的存取控制,則設定max_clause_count為 1 會導致網域發生問題。我們建議您將此帳戶設定為較高的數字。

  • 如果您要在未設定精細存取控制的網域中啟用精細的存取控制,則針對為直接查詢建立的資料來源,您必須自行設定精細的存取控制角色。如需如何設定精細存取角色的詳細資訊,請參閱建立 Amazon OpenSearch 服務資料來源與 Amazon S3 整合

修改主要使用者

如果您忘記了主要使用者的詳細資訊,您可以使用主控台、 AWS CLI或組態 API 來重新設定。

修改主要使用者 (主控台)
  1. 導航到 Amazon OpenSearch 服務控制台 https://console.aws.amazon.com/aos/home/.

  2. 選取網域,並選擇 Actions (動作)、Edit security configuration (編輯安全組態)。

  3. 選擇 Set IAM ARN as master user (將 IAM ARN 設為主要使用者) 或 Create master user (建立主要使用者)。

    • 如果您先前使用了 IAM 主要使用者,精細存取控制會將 all_access 角色重新映射到您指定的新 IAM ARN。

    • 如果您先前使用了內部使用者資料庫,則精細存取控制會建立新的主要使用者。您可以使用新的主要使用者來刪除舊的主要使用者。

    • 從內部使用者資料庫切換至 IAM 主要使用者不會刪除內部使用者資料庫中的任何使用者。相反,它只是停用 HTTP 基本身分驗證。從內部使用者資料庫手動刪除使用者,或者保留它們,以防您需要重新啟用 HTTP 基本身分驗證。

  4. 選擇儲存變更

其他主要使用者

您可以在建立網域時指定主要使用者,但是如果您希望的話,您可以使用這個主要使用者來建立其他主要使用者。您有兩個選項: OpenSearch 儀表板或其餘 API。

  • 在 Dashboards 中,選擇 Security (安全性)、Role (角色),然後將新的主要使用者映射到 all_accesssecurity_manager 角色。

    角色映射頁面
  • 如要使用 REST API,請傳送下列請求:

    PUT _plugins/_security/api/rolesmapping/all_access { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }
    PUT _plugins/_security/api/rolesmapping/security_manager { "backend_roles": [ "arn:aws:iam::123456789012:role/fourth-master-user" ], "hosts": [], "users": [ "master-user", "second-master-user", "arn:aws:iam::123456789012:user/third-master-user" ] }

    這些請求會「取代」目前的角色映射,因此請先執行 GET 請求,讓您可以在 PUT 請求中包含所有目前的角色。在您無法存取 Dashboards 而又希望將 Amazon Cognito 的 IAM 角色映射到 all_access 角色時,REST API 特別有用。

手動快照

精細存取控制在擷取手動快照時複雜度較高。若要註冊快照儲存庫 (即使將 HTTP 基本身分驗證用於所有其他用途),您必須將 manage_snapshots 角色映射至具備 iam:PassRole 許可能夠擔任 TheSnapshotRole 的 IAM 角色,如 必要條件 中所定義。

然後使用該 IAM 角色將簽章的請求傳送到網域,如 註冊手動快照儲存庫 中所述。

整合

如果您將其他服 AWS 務與 OpenSearch 服務搭配使用,則必須以適當的許可為這些服務提供 IAM 角色。例如,Firehose 交付串流通常使用稱為firehose_delivery_role的 IAM 角色。在 Dashboards 中,建立精細存取控制的角色,然後將 IAM 角色映射到該角色。在此案例中,新的角色需要下列許可:

{ "cluster_permissions": [ "cluster_composite_ops", "cluster_monitor" ], "index_permissions": [{ "index_patterns": [ "firehose-index*" ], "allowed_actions": [ "create_index", "manage", "crud" ] }] }

許可會因每個服務執行的動作而不同。索引資料的 AWS IoT 規則或 AWS Lambda 函數可能需要與 Firehose 類似的權限,而只執行搜尋的 Lambda 函數則可以使用更有限的集合。

REST API 差異

細粒度的訪問控制 REST API 略有不同,具體取決於您的 OpenSearch/彈性搜索版本。在提出 PUT 請求前,請先提出 GET 請求以驗證預期的請求主體。例如,向 _plugins/_security/api/user 提出的 GET 請求會傳回所有使用者,讓您可以接著進行修改並用來提出有效的 PUT 請求。

在 Elasticsearch 6.x 上,建立使用者的請求如下所示:

PUT _opendistro/_security/api/user/new-user { "password": "some-password", "roles": ["new-backend-role"] }

在 OpenSearch 或彈性搜索 7.x 上,請求看起來像這樣(_opendistro如果使用彈性搜索,則更改_plugins為):

PUT _plugins/_security/api/user/new-user { "password": "some-password", "backend_roles": ["new-backend-role"] }

此外,租用戶在 Elasticsearch 6.x 中是角色的屬性。

GET _opendistro/_security/api/roles/all_access { "all_access": { "cluster": ["UNLIMITED"], "tenants": { "admin_tenant": "RW" }, "indices": { "*": { "*": ["UNLIMITED"] } }, "readonly": "true" } }

在 OpenSearch 和彈性搜索 7.x 中,它們是具有自己的 URI 的對象(_opendistro如果使用彈性搜索,則更改_plugins為):

GET _plugins/_security/api/tenants { "global_tenant": { "reserved": true, "hidden": false, "description": "Global tenant", "static": false } }

如需 OpenSearch REST API 的相關文件,請參閱安全性外掛程式 API 參考資料

提示

如果您使用內部用戶資料庫,則可以使用 curl 發出請求並測試您的網域。嘗試以下範例命令:

curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_search' curl -XGET -u 'master-user:master-user-password' 'domain-endpoint/_plugins/_security/api/user'