首先:在引入UAA之前,Cloud Controller(简称CC)自己做身份验证,将用户存储在psql db中。
后来他们发现 CC 应该专注于应用程序/服务管理,并将身份验证委托给一个新组件/authorization/usermanagement,他们将其命名为:用户帐户和身份验证 (UAA) 服务器
UAA 主要是一个 oauth2 提供者,这意味着将令牌提供给客户。但是 oauth 术语中的客户端是代表用户(oauth 术语中的资源所有者)的 vmc/CC 之类的应用程序
echo 'select client_id, scope from oauth_client_details;' | sudo psql -U root uaa
client_id | scope
------------------+--------------------------------------------------------------------
admin | uaa.none
vmc | cloud_controller.read,cloud_controller.write,openid,password.write
cloud_controller | uaa.none
UAA 还能够进行身份管理,即能够存储用户及其密码。他们正在实施 SCIM 标准(跨域身份管理系统)。默认情况下,它使用 postgres 来存储用户:
echo 'select * from users;' | sudo psql -U root uaa
实际上,现在在我的 vcap 上,所有用户都将由 cloud_controller 的 postgres 数据库存储,无论 cloud_controller.yml 设置如何。但是请注意,正如您在过去几天的 git 提交中所看到的那样,CC - UAA 连接正在大改中:
在过去的几天里,我多次从 git 中提取最新代码,有时新用户会进入 CC 的数据库,有时他们会进入 UAA 的数据库。它有时还取决于 vmc 版本...
根据您的描述,我猜您的用户在 CC 的数据库中。您可以自行检查。
您可以将 cloud_controllers postgres db 中的用户列为:
echo 'select * from users;' | sudo -u postgres psql cloud_controller
注意活动列。如果启用了UAA,则两个数据库都存储用户,但UAAdb中的active=true和CCdb中的active=false
因此,您最安全的选择是禁用 CC 的 UAA 委托,如图所示,在 cloudfoundry/.deployments/devbox/config/cloud_controller.yml
的第 77 行附近
uaa:
enabled: false
在更改任何配置文件后,您必须重新启动受影响的组件,在这种情况下 CC:
~/cloudfoundry/vcap/dev_setup/bin/vcap_dev restart cloud_controller