Geekly Articles each Day

SSOとKibana：統合Windows認証とのKibana統合（シングルサインオン）

この記事では、Elastic Stackでシングルサインオン（SSO）テクノロジーを構成する方法を共有します。これは、X-Packを使用してユーザーを認証し、データアクセスを制限します。


SSOを停止


KibanでActive Directoryを使用してSSOを構成する積極的な試みは、記事「 サードパーティの認証とKibanaの統合 」を読んだ後に始まったと言わなければなりません。 いつものように、シンプルで実用的な例がそのようなブログで提供されました。これは「家庭での使用」に適していますが、複雑なインフラストラクチャを備えた企業ではほとんど役に立ちません。 そして、Elastic Stack v.5.6.2、より具体的には-X-Pack 5.6.2のパッチがリリースされて、最終的にActive Directoryで「ユーザー偽装」を使用できるようになり、シングルサインオン（SSO）が完全に機能しました。少なくとも。


「ユーザーのなりすまし」はこのシステムの重要なコンポーネントであり、1つのアカウント（たとえば、技術ユーザー）が他の既に認証されたユーザーに代わってリクエストを送信できるようにします。 Elastic Stack X-Packでは、この関数はrun_asと呼ばれます 。


公平に言うと、LDAPを使用している場合、このパッチの前にSSOを構成できることに注意してください。 ただし、ElasticsearchのLDAPレルムはネストされたグループをサポートしていないため、このソリューションを検討することは重大な考慮事項ではありませんでした。


建築


提案されたソリューションのアーキテクチャは次のようになります。



画像は前述のブログから借用したもので、いくつかのコンポーネントの名前のみが変更されています。 Elasticが（気付いたとしても）気にしないことを望みます。気が付いたら、PPTで自分の正方形を描く必要があります。


職務内容



設置



構成


すべてのコンポーネントの構成を開始します（夢はインストーラーを書くことです...）。


IIS



 openssl pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt 


 Enable proxy [x] Reverse proxy: localhost:5601


ヘリコン書き換えエンジン


デフォルトでは、モジュールはC:\Program FilesインストールされC:\Program Files 。
以下を構成ファイルC:\Program Files\Helicon\ISAPI_Rewrite3\httpd.conf追加しますC:\Program Files\Helicon\ISAPI_Rewrite3\httpd.conf ：


 RewriteEngine on RewriteCond %{REMOTE_USER} (.*)\\(.*) RewriteHeader es-security-runas-user: .* (%2)(@company.com) RewriteHeader Authorization: .* (Basic\ aWlzOnNlY3JldHBhc3N3b3Jk) RewriteRule ^/logout / [R,L]

仕組み：



キバナ


SSOの場合、次のパラメーターをkibana.yml追加します。


 elasticsearch.requestHeadersWhitelist: [ es-security-runas-user, authorization ] xpack.monitoring.elasticsearch.requestHeadersWhitelist: [ es-security-runas-user, authorization ]

Elasticsearch


X-Packは既にインストールされていますelasticsearch.yml ADを構成します。


 xpack: security: authc: realms: native_realm: type: native order: 0 company_ad_realm: enabled: true type: active_directory order: 1 domain_name: company.com user_search: base_dn: "DC=company,DC=com" group_search: base_dn: "DC=company,DC=com" url: ldaps://server.company.com:636 ssl.verification_mode: none bind_dn: "CN=user,OU=People,DC=company,DC=com" bind_password: "XXXXXXXXXX" unmapped_groups_as_roles: true cache.ttl: 300s

bind_dn指定されたユーザーには、ADに接続して検索する権限が必要です。
AD認証局（CA）が指定されていないため（パラメーター： ssl.certificate_authorities ）、AD証明書の検証は無効になっています（ ssl.verification_mode: none ）。


Elasticsearchで技術ユーザー（ iis ）と、なりすまし（「ユーザーのなりすまし」-さらに悪いことに聞こえiis ）のロール（ iis ）を作成しiis 。


POST _xpack/security/role/iis


 { "run_as": [ "*@company.com" ] }

POST _xpack/security/user/iis


 { "password": "secretpassword", "roles": [ "iis" ], "full_name": "Service Account for IIS reverse proxy" }

次に、すべてのKibanaユーザーのロールを作成します。 思い出させてください-ロール名は、メンバーがKibanaにアクセスできるADのグループの名前である必要があります（このグループを「ELK.Users」と呼びます）。


POST _xpack/security/role/ELK.Users


 { "indices": [ { "names": [ ".kibana*" ], "privileges": ["read", "manage", "index", "delete"] } ] }

.kibanaはすべての設定を1つのインデックス（ .kibanaまたは.kibana-6 ）に.kibana-6ため、すべての.kibana-6ユーザーはそのインデックスに対する読み取りおよび書き込み権限を持っている必要があります。


次に、例として、ネットワークデバイスからのデータが格納されているnet-*インデックスにアクセスできるメンバーを持つロールを作成します。


POST _xpack/security/role/ELK.Network.Admins


 { "indices": [ { "names": [ "net-*" ], "privileges": ["read", "view_index_metadata"] } ] }

もう1つの例は、Elasticsearch 2管理者の「カスタム」スーパーユーザーロールです。


POST _xpack/security/role/ELK.Admins


 { "cluster": [ "all" ], "indices": [ { "names": [ "*" ], "privileges": [ "all" ] } ] }

したがって、ADグループ「ELK.Admins」のメンバーは、Elasticsearchクラスターへのフルアクセスを取得します。


結果


電源を入れてびっくり！ ログインの入力を忘れることがあります。



IISプロキシサイトのルートページを開くと、ユーザーは正常に認証されました。
注：このユーザーがnet-*インデックスnet-*のみにアクセスできる場合、ユーザーはKibanのすべての構成済みインデックスを引き続き表示します。ドロップダウンリストに注意してください。 ただし、アクセスできないインデックスを選択すると、ユーザーには「 結果が見つかりません」と表示されます。 ただし、この問題はSSOとは関係ありません。


「問題が発生しました。」


テストとトラブルシューティング。


ケース1 ：ユーザー（またはそのグループ）がADグループに「 ELK.Usersユーザー」（ ELK.Users ）を追加するのを忘れたか、 ELK.Usersアクセスできない場合：


 Config: Error 403 Forbidden: action [indices:data/write/update] is unauthorized for user [iis] run as [user@company.com]: [security_exception] action [indices:data/write/update] is unauthorized for user [iis] run as ...

エラー403禁止


ユーザーはIIS（NTLM、Kerberosなど）によって正常に認証され、技術ユーザーiisはKibanで認証されました。 しかし、以来 実際のuser@company.comアカウントは「Kibana lovers」のADグループのメンバーではないため、 .kibanaインデックスの書き込み/読み取りの役割もありません。
メッセージや「アクセス拒否」ページをより「フレンドリー」にする方法はまだわかりません。


ケース2 ：IISはプロキシモジュール構成でSSLを使用し（意図したとおり、[SSLオフロードを有効にする]オプションが無効になっています）、KibanではHTTPSの構成を忘れていました。 その後、 kibana.log次のことを確認できます。


 {"type":"log","@timestamp":"2017-10-03T15:11:32Z","tags":["connection","client","error"],"pid":10416,"level":"error","message":"Parse Error","error":{"message":"Parse Error","name":"Error","stack":"Error: Parse Error\n at Error (native)","code":"HPE_INVALID_METHOD"}}

ケース3 ：Kibana証明書に署名した証明機関がIISに認識されていない
IIS-Kibanaの開始ページを開きます。


 HTTP Error 502.3 - Bad Gateway A security error occurred

Kibanaログの対応するエラー：


 "code":"ECONNRESET" "message":"socket hang up"

ケース4 ：WebサイトでWindows認証が有効になっていない
その後、ユーザーはiisユーザーとしてKibanで認証されiis ：「IISリバースプロキシのサービスアカウント」


テスト1 ：AD / LDAPで問題ありませんか？ そして、メンバーシップはどうですか？
ldapsearchまたはadfindを使用します- ここからダウンロードすることを強くお勧めします


 ldapsearch -h server.company.com -b "DC=company,DC=com" -D "CN=user,OU=People,DC=company,DC=com" -w "XXXXXXX" samaccountname=user adfind -f "userprincipalname=user@company.com"

テスト2 ：なりすましのテスト


 curl -k -v -u iis:secretpassword -H "es-security-runas-user: user@company.com" https://elastic-server:9200/.kibana/_search

このテストに合格した場合（ HTTP/1.1 200 OK ）、Elasticsearchは正しく構成され、ADのユーザー権限を確認できます。
さて、次のようなものが得られたら：


 {"error":{"root_cause":[{"type":"security_exception","reason":"action [indices:data/read/search] is unauthorized for user [iis] run as [user@company.com]"}],"type":"security_exception","reason":"action [indices:data/read/search] is unauthorized for user [iis] run as [user@company.com]"},"status":403}

デバッグを有効にして、Elasticsearchのログを読み取ります。
PUT /_cluster/settings


 { "transient": { "logger.org.elasticsearch.xpack.security.authc": "trace" } }

テスト3 ：ADのユーザーのメンバーシップを変更し、Elasticsearchがキャッシュの無効化を予期しないように、手動でクリアします


 curl -k -u 'elastic:changeme' -X POST https://elastic-server:9200/_xpack/security/realm/company_ad_realm/_clear_cache

注： elasticは、デフォルトのパスワード（バージョン5.x）または同じパスワード（バージョン6.x）に変更された組み込みユーザーです。


やること



 { statusCode: 500, error: Internal Server Error, message: An internal server error occurred }

原則として、同じHelicon Rewriteで、次の場所に配置できるカスタムページにこのエラーが表示されたときにリダイレクトを記述できます。


 <kibana-home>\optimize\bundles

このページは次の場所で利用できます。


 https://localhost/bundles/custom/error.htm

ご清聴ありがとうございました！


組織の「ユーザーエクスペリエンス」やその他の「満足度」のレベルがさらに高まることを願っています。



[1] unmapped_groups_as_roles: trueを使用する場合は、次の安全性とパフォーマンスの考慮事項を考慮する必要がありunmapped_groups_as_roles: true



それでも、上記の理由でADグループを介してこの自動マッピングを使用しないことにした場合、ファイルまたはAPIを介してロールのグループを表示する必要があります 。 ↩


[2]製品にそのようなスーパーユーザーの役割を作成することは推奨されません。 スーパーユーザーelasticとしてcurl使用して、昔ながらの方法で管理することをおcurlます。 ↩



Source: https://habr.com/ru/post/J350744/

More articles:


All Articles