LDAP サービスディレクトリグループを Kong ロールにマッピングする
サービスディレクトリマッピングにより、組織はKong Gatewayでの認証と承認にLDAPディレクトリを使用できるようになります。
必要な構成でKong Gatewayを開始した後、ユーザー名がLDAPディレクトリ内のユーザー名と一致する新しい管理者を作成できます。その後、これらのユーザーはKong Managerへの招待を受け入れ、LDAP認証情報でログインできるようになります。
Kongでのサービスディレクトリマッピングの仕組みは以下のとおりです。
- ロールは、Admin APIまたはKong Managerを使用してKong Gatewayに作成されます。
- グループが作成され、ロールがグループに関連付けられます。
- ユーザーがKong Managerにログインすると、所属するグループに基づいて権限が付与されます。
たとえば、サービスディレクトリでユーザーのグループが変更されると、次にKong Managerにログインしたときに、 Kong GatewayでKong管理者アカウントに関連付けられたロールも変更されます。このマッピングにより、サービスディレクトリが記録システムになるため、Kong Gatewayで手動でアクセスを管理する手間が省けます。
LDAPサービスディレクトリマッピングを使用すると、管理者に割り当てられたロールはサービスディレクトリによって管理されます。 管理者ロールの割当や割当解除を手動で行った場合、変更内容は次回のログインで上書きされます。
前提条件
- Kong Gatewayがインストールおよび構成済み
- Kong Managerのアクセス
- ローカルの LDAP ディレクトリがある
LDAP認証を有効化
LDAPディレクトリを認証と承認に使用するようにサービスディレクトリマッピングを設定します。
-
Kong Gatewayを起動します。シェルから、次のように入力します。
kong start [-c /path/to/kong/conf]
-
LDAP Authenticationを有効にし、Kong ManagerのRBACを適用するには、次のプロパティで
kong.conf
を通じてKongを構成します。enforce_rbac = on admin_gui_auth = ldap-auth-advanced admin_gui_session_conf = { "secret":"set-your-string-here" }
Kong Managerはバックグラウンドでセッションプラグインも使用します。このプラグイン(
admin_gui_session_conf
で構成)にはシークレットが必要であり、デフォルトで安全に構成されています。- どのような状況においても、
secret
は手動で文字列に設定する必要があります。 - HTTPSではなくHTTPを使用する場合は、
cookie_secure
を手動でfalse
に設定する必要があります。* Admin APIとKong Managerに異なるドメインを使用する場合、cookie_same_site
をLax
に設定する必要があります。
これらのプロパティの詳細については、Kong ManagerのSessionセキュリティを参照し、構成例を確認してください。
- どのような状況においても、
LDAP認証の構成
次のプロパティを使用してKong ManagerのLDAP認証を構成します。以下に定義する属性変数に注意してください。
admin_gui_auth_conf = {
"anonymous":"", \
"attribute":"<enter_your_attribute_here id="sl-md0000000">", \
"bind_dn":"<enter_your_bind_dn_here id="sl-md0000000">", \
"base_dn":"<enter_your_base_dn_here id="sl-md0000000">", \
"cache_ttl": 2, \
"header_type":"Basic", \
"keepalive":60000, \
"ldap_host":"<enter_your_ldap_host_here id="sl-md0000000">", \
"ldap_password":"<enter_your_ldap_password_here id="sl-md0000000">", \
"ldap_port":389, \
"start_tls":false, \
"timeout":10000, \
"verify_ldap_host":true, \
"consumer_by":["username", "custom_id"], \
"group_base_dn":"<enter_your_group_base_dn_here id="sl-md0000000">",
"group_name_attribute":"<enter_your_group_name_attribute_here id="sl-md0000000">",
"group_member_attribute":"<enter_your_group_member_attribute_here id="sl-md0000000">",
}
属性 | 説明 |
---|---|
attribute |
LDAPユーザーを識別するために使用される属性。 たとえば、LDAPユーザーをユーザー名で管理者にマッピングするには、 uid を設定します。 |
bind_dn |
LDAPバインドDN(識別名)。ユーザーのLDAP検索を実行するために使用されます。このbind_dn には、認証中のユーザーを検索する権限が必要です。たとえば、 uid=einstein,ou=scientists,dc=ldap,dc=com 。 |
base_dn |
LDAPベースDN(識別名)。ou=scientists,dc=ldap,dc=com はその一例です。 |
ldap_host |
LDAPホストドメイン。 たとえば、 ec2-XX-XXX-XX-XXX.compute-1.amazonaws.com 。 |
ldap_port |
デフォルトのLDAP ポートは389です。636はSSL LDAPおよびADに必要なポートです。ldaps が構成されている場合は、ポート636を使用する必要があります。より複雑なActive Directory(AD)環境では、ドメインコントローラーとポート389の代わりに、グローバルカタログのホストとポートの使用を検討してください。デフォルトではポート3268を使用します。 |
ldap_password |
LDAP パスワード。 他の構成プロパティと同様に、機密情報は構成ファイルに直接書き込むのではなく、環境変数として設定できます。 |
group_base_dn |
LDAPがグループの検索を開始するエントリの識別名を設定します。 デフォルトは conf.base_dn の値です。 |
group_name_attribute |
グループの名前を保持する属性を設定します。通常、 name (Active Directoryの場合)またはcn (OpenLDAP の場合)と呼ばれます。デフォルトは conf.attribute からの値です。 |
group_member_attribute |
LDAPグループのメンバーを保持する属性を設定します。 デフォルトは memberOf です。 |
ロール権限を定義する
Admin APIのRBAC エンドポイントを使用するか、Kong Managerのチームページを使用して、 Kong Gatewayで権限を持つロールを定義します。次のいずれかを使用して、どのKongロールがサービスディレクトリの各グループに対応するかを手動で定義する必要があります。
- Kong Managerのディレクトリマッピングセクション。 Teams > Groups タブにあります。
- Admin APIのディレクトリマッピングエンドポイントを使用します。
Kong Gatewayはサービスディレクトリに書き込みません。たとえば、 Kong Gateway管理者はディレクトリ内にユーザーまたはグループを作成できません。ユーザーとグループをKong Gatewayにマッピングする前に、個別に作成する必要があります。
ユーザーと管理者のマッピング
サービス ディレクトリ ユーザーを Kong 管理者にマップするには、管理者のユーザー名をadmin_gui_auth_conf
で構成された属性に対応する 名前 の値にマップします。Kong Managerで管理者アカウントを作成するか、Admin APIを使用します。
ブートストラップされたスーパーアドミンとディレクトリユーザーでペアを組む方法に関する手順については、ディレクトリユーザーを最初のスーパーアドミンとして設定を参照してください。
既にロールが割り当てられている管理者がいる状態で、代わりにグループマッピングを使用する場合は、最初にすべてのロールを削除する必要があります。サービスディレクトリは、ユーザー権限の記録システムとして機能します。割り当てられたロールは、グループからマップされたロールに加えて、ユーザーの権限にも影響します。
グループロールの割り当て
サービスディレクトリマッピングを使用すると、グループがロールにマッピングされます。ユーザーがログインすると、管理者のユーザー名で識別され、サービスディレクトリで一致するユーザー認証情報で認証されます。 その後、サービスディレクトリ内のグループは、組織が定義した関連する役割と自動的に対応付けられます。
例
- Example Corpは、サービスディレクトリグループ
T1-Mgmt
を Kongのロールのスーパー管理者にマッピングします。 - Example Corpは、
example-user
という名前のサービスディレクトリユーザーを、同じ名前example-user
のKong管理者アカウントにマッピングします。 - ユーザー
example-user
は、LDAP ディレクトリ内のグループT1-Mgmt
に割り当てられています。
example-user
がKong Managerに管理者としてログインすると、マッピングの結果として自動的にスーパー管理者ロールが与えられます。
Example CorpがT1-Mgmt
への割り当てを削除してexample-user
の権限を取り消すことにした場合、ログインしようとするとスーパー管理者の役割が失われます。
ディレクトリユーザーを最初のスーパー管理者として設定
Kong は、ディレクトリユーザーを最初のスーパー管理者として設定することを推奨しています。
この例では、一意の識別子(UID)を使用して構成された属性と、スーパー管理者にしたいディレクトリユーザーが、UID=example-user
という識別名(DN)エントリを持っていることを示しています。
curl -i -X PATCH https://localhost:8001/admins/kong_admin \
--header 'Kong-Admin-Token: <rbac_token id="sl-md0000000">' \
--header 'Content-Type: application/json' \
--data '{"username":"example-user"}'
このユーザーはログインできますが、example-user
に属するグループをロールにマップするまで、ユーザーはディレクトリを認証にのみ使用します。example-user
が属するグループにスーパー管理者ロールをマップすると、example-user
管理者からスーパー管理者ロールを削除できます。選択するグループは、ディレクトリ内で「スーパー」である必要があります。そうでない場合、他の管理者が例えば「従業員」グループなどの一般的なグループでログインすると、彼らもスーパー管理者になってしまいます。
重要 :唯一のadminからスーパー管理者ロールを削除し、そのスーパー管理者ロールをadminが属するグループにまだマッピングしていない場合、Kong Managerにログインできません。
代替案:
-
RBACをオフにしてKongを起動し、グループをスーパー管理者ロールにマッピングしてから、そのグループに属するユーザーに対応する管理者を作成します。そうすることで、スーパー管理者の権限が完全にディレクトリグループに関連付けられるのに対し、スーパー管理者のブートストラップでは、認証のためだけにディレクトリを使用します。
-
RBACを適用する前に、一致するディレクトリユーザーのすべての管理者アカウントを作成し、既存のグループが適切なロールにマップされていることを確認します。