1.8. 配置 Identity Service
这些步骤准备 Identity Service 与 AD DS 集成。
1.8.1. 启用 keystone v3 的命令行访问 复制链接链接已复制到粘贴板!
要从命令行管理 Identity Service 域,您需要启用对 keystone v3 的访问。
从运行 keystone 服务的控制器执行此步骤。
1.创建现有环境变量文件的副本。在基于 director 的部署中,它将称为 overcloudrc
:
cp overcloudrc overcloudrc-v3
$ cp overcloudrc overcloudrc-v3
2.编辑新的 overcloudrc-v3
文件:
-
将
OS_AUTH_URL
从 v2.0 更改为 v3。例如:
export OS_AUTH_URL=https://controllerIP:5000/v3/
export OS_AUTH_URL=https://controllerIP:5000/v3/
-
将以下条目添加到
overcloudrc-v3
的底部:
export OS_IDENTITY_API_VERSION=3 export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
3.通过提供文件,为您的当前命令行会话启用这些选项:
source overcloudrc-v3
$ source overcloudrc-v3
1.8.2. 配置控制器 复制链接链接已复制到粘贴板!
从运行 keystone 服务的控制器执行此步骤。如果运行具有多个控制器的 HA 环境,则必须在每个控制器上执行这些步骤:
1.配置 SELinux:
setsebool -P authlogin_nsswitch_use_ldap=on
# setsebool -P authlogin_nsswitch_use_ldap=on
输出可能包含类似如下的消息。可以忽略它们:
Full path required for exclude: net:[4026532245].
Full path required for exclude: net:[4026532245].
2.创建 domains 目录:
mkdir /etc/keystone/domains/ chown keystone /etc/keystone/domains/
# mkdir /etc/keystone/domains/
# chown keystone /etc/keystone/domains/
3.配置 Identity Service 以使用多个后端:
您可能需要使用 yum install
安装 crudini。
crudini
crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains crudini --set /etc/keystone/keystone.conf assignment driver sql
# crudini --set /etc/keystone/keystone.conf identity domain_specific_drivers_enabled true
# crudini --set /etc/keystone/keystone.conf identity domain_config_dir /etc/keystone/domains
# crudini --set /etc/keystone/keystone.conf assignment driver sql
如果使用 Red Hat OpenStack Platform director,则需要注意 /etc/keystone/keystone.conf 由 Puppet 管理。因此,每当您运行 openstack overcloud deploy
过程时,您添加的任何自定义配置都可能会被覆盖。因此,您可能需要每次手动重新添加此配置。以后的 director 版本会包括 Puppet 参数,允许您使用部署后脚本自动重新应用这些设置。
4.配置额外的后端:
在本例中,LAB
是要用作 Identity Service 域的 NetBIOS 名称。
a.为 AD DS 集成创建 keystone 域。
使用之前检索的 NetBIOS 名称值作为域名。这种方法允许您在登录过程中向用户显示一致的域名。例如,如果 NetBIOS 名称为 LAB
:
openstack domain create LAB
# openstack domain create LAB
如果这个命令不可用,请通过运行 # source overcloudrc-v3
来检查您为命令行会话启用了 keystone v3。
b.创建配置文件:
要添加 AD DS 后端,请在名为 /etc/keystone/domains/keystone.LAB.conf 的新文件中输入 LDAP 设置(其中 LAB
是前面检索到的 NetBIOS 名称)。您需要编辑以下示例设置以适合您的 AD DS 部署:
每个设置的说明:
设置 | 描述 |
---|---|
|
用于身份验证的 AD 域控制器。使用 LDAPS 端口 |
|
用于 LDAP 查询的 AD 帐户 的可辨识名称。例如,您可以使用 |
| 上面使用的 AD 帐户的明文密码。 |
|
AD 域 的可辨识名称。您可以使用 |
| 包含 OpenStack 帐户的组织单元(OU)。 |
|
定义 LDAP 用户的类型。对于 AD,请使用 |
|
过滤提供给 Identity Service 的用户。因此,只有 grp-openstack 组的成员可以在 Identity Service 中定义权限。这个值需要组的完整可辨识名称: |
| 映射用于用户 ID 的 AD 值。 |
| 映射用于 名称 的 AD 值。 |
| 映射用于用户电子邮件地址的 AD 值。 |
| 将此值设置为。 |
| 验证是否启用了帐户的 AD 设置。 |
| 定义要检查以确定是否启用帐户的值。在不返回布尔值时使用。 |
| 表示启用了帐户的 AD 值。 |
| 定义 Identity Service 应该忽略的用户属性。 |
|
将此值设置为 |
|
将此值设置为 |
|
将此值设置为 |
| 映射要用于 组的 AD 值。 |
| 包含用户组的机构单元 (OU)。 |
| 过滤为 Identity Service 提供的组。 |
| 映射用于组 ID 的 AD 值。 |
| 映射用于组名称的 AD 值。 |
|
将此值设置为 |
|
将此值设置为 |
|
将此值设置为 |
| 定义是否使用 TLS。如果您使用 LDAPS 而不是 STARTTLS 加密,则需要禁用此设置。 |
| 指定 .crt 证书文件的路径。 |
|
在查找属于 |
|
设置为 |
6.将配置文件的所有权更改为 keystone 用户:
chown keystone /etc/keystone/domains/keystone.LAB.conf
# chown keystone /etc/keystone/domains/keystone.LAB.conf
7.将控制面板配置为在登录页面中使用 LAB
keystone 域。将这些行添加到 /etc/openstack-dashboard/local_settings 中:
此 Red Hat OpenStack Platform 版本不支持多域仪表板配置。因此,本指南只描述了单个域的 Dashboard 配置。
OPENSTACK_API_VERSIONS = { "identity": 3 } OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
OPENSTACK_API_VERSIONS = {
"identity": 3
}
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'LAB'
如果使用 Red Hat OpenStack Platform director,则需要注意 /etc/openstack-dashboard/local_settings 由 Puppet 管理。因此,每当您运行 openstack overcloud deploy
过程时,您添加的任何自定义配置都可能会被覆盖。因此,您可能需要每次手动重新添加此配置。以后的 director 版本会包括 Puppet 参数,允许您使用部署后脚本自动重新应用这些设置。
8.重启 httpd 服务以应用更改:
systemctl restart httpd.service
# systemctl restart httpd.service
9.授予 admin 用户对域的访问权限:
这不授予 OpenStack admin 帐户实际 AD DS 域的任何权限。在这种情况下,术语域指的是 OpenStack Keystone 域的使用。
a.获取 LAB
域的 ID
:
b.获取 admin 用户的 ID
值:
openstack user list --domain default | grep admin
# openstack user list --domain default | grep admin
| 3d75388d351846c6a880e53b2508172a | admin |
c.获取 admin 角色的 ID
值:
d.使用返回的域和 admin ID 构造命令,将 admin 用户添加到 keystone LAB 域的 admin 角色中:
openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
# openstack role add --domain 6800b0496429431ab1c4efbb3fe810d4 --user 3d75388d351846c6a880e53b2508172a 785c70b150ee4c778fe4de088070b4cf
10.通过在命令中添加 NetBIOS 名称来查看 AD DS 域中的用户列表:
可能需要过些时间,LDAP 才能在重新启动或服务重启后变为查询。
openstack user list --domain LAB
# openstack user list --domain LAB
11.查看本地 Identity Service 数据库中的服务帐户:
openstack user list --domain default
# openstack user list --domain default
1.8.3. 将 Compute 配置为使用 keystone v3 复制链接链接已复制到粘贴板!
默认情况下,计算使用 keystone v2.0,因此需要配置为使用 keystone v3,才能使用多域功能。
1.在每个 Compute 节点上,调整 keystone_authtoken
值:
crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
# crudini --set /etc/nova/nova.conf keystone_authtoken auth_version v3
2.在控制器中重启这些服务以应用更改:
systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
# systemctl restart openstack-nova-api.service openstack-nova-cert.service openstack-nova-conductor.service openstack-nova-consoleauth.service openstack-nova-novncproxy.service openstack-nova-scheduler.service
3.在每个 Compute 节点上重启这个服务以应用更改:
systemctl restart openstack-nova-compute.service
# systemctl restart openstack-nova-compute.service
1.8.4. 配置块存储以使用 keystone v3 复制链接链接已复制到粘贴板!
您还必须配置 Block Storage (cinder)来向 keystone v3 进行身份验证。
在 /etc/cinder/cinder.conf 中:
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
[keystone_authtoken] auth_uri = https://controllerIP:5000/v3 auth_version = v3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
auth_uri
- 将controllerIP
替换为控制器的 IP 地址。如果您的部署有多个控制器,您应该使用 keystone 端点 VIP,而不是控制器 IP。
-
1.8.5. 允许 Active Directory 组成员访问项目 复制链接链接已复制到粘贴板!
要允许经过身份验证的用户访问 OpenStack 资源,建议的方法是授权某些 Active Directory 组授予对项目的访问权限。这会节省 OpenStack 管理员,无需将每个用户分配给项目中的角色。相反,Active Directory 组在项目中被授予角色。因此,作为这些 Active Directory 组的成员的 Active Directory 用户将能够访问预先确定的项目。
如果您希望手动管理单个活动目录用户的授权,请参阅以下部分: 允许单个 Active Directory 用户访问项目
本节假定 Active Directory 管理员已完成这些步骤:
-
在 Active Directory 中创建名为
grp-openstack-admin
的组。 -
在 Active Directory 中创建名为
grp-openstack-demo
的组。 - 根据需要,将您的 Active Directory 用户添加到上述组中之一。
-
将您的 Active Directory 用户添加到
grp-openstack
组。
这些步骤会为 AD 组分配角色。然后,组成员将具有访问 OpenStack 资源的权限。
1.检索 AD 组列表:
2.检索角色列表:
3.通过将活动目录组添加到一个或多个角色来授予 Active Directory 组对项目的访问权限。例如,如果您希望 grp-openstack-demo
组中的用户是 demo 项目的普通用户,您必须将该组添加到 member 角色中:
openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
# openstack role add --project demo --group d971bb3bd5e64a454cbd0cc7af4c0773e78d61b5f81321809f8323216938cae8 _member_
因此,grp-openstack-demo
的成员可以通过输入 AD DS 用户名和密码登录到仪表板。
如果用户收到错误 "Error: Unable to retrieve container list.",并且希望能够管理容器,则必须将它们添加到 SwiftOperator 角色中。
1.8.6. 允许 Active Directory 用户访问项目 复制链接链接已复制到粘贴板!
属于 grp-openstack AD 组的成员的 AD DS 用户可以授予在仪表板中登录到项目的权限:
1.检索 AD 用户列表:
2.检索角色列表:
3.通过将项目添加到一个或多个这些角色,授予用户对项目的访问权限。例如,如果您希望 user1 是 demo 项目的普通用户,您可以将它们添加到 member 角色中:
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e _member_
或者,如果您希望 user1 是 demo 项目的管理用户,您可以将它们添加到 admin 角色中:
openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
# openstack role add --project demo --user 1f24ec1f11aeb90520079c29f70afa060d22e2ce92b2eba7784c841ac418091e admin
因此,user1 可以通过输入 AD DS 用户名和密码来登录仪表板。
如果用户收到错误 "Error: Unable to retrieve container list.",并且希望能够管理容器,则必须将它们添加到 SwiftOperator 角色中。