Read-only mode

[jmcarp]

My team would like to run admin-ui with read permissions only, since we rarely use it for writes and would like to scale back the permissions we give to the application. Can we just drop the client authorities from cloud_controller.admin to cloud_controller.global_auditor and omit database credentials? It would also be useful to have a read-only mode for the application that drops UI around writes.

cc @wjwoodson @brittag

[rboykin]

@jmcarp If you only give your admin ui users your selection for uaa_groups_user (see the readme), those users won't be able to exercise any actions.

[rboykin]

@jmcarp Also realize that UAA-related actions are not controlled by cloud_controller.admin, but specific UAA permissions.

[jmcarp]

Right, so we'll drop uaa authorities related to writes for cloud controller and uaa, and drop database credentials entirely. Does that sound right?

[rboykin]

@jmcarp If you drop database credentials, then the admin ui won't be able to retrieve CCDB or UAADB records. The admin ui does not use the CC API to retrieve information (or at least not much information), but only for non-read operations.

I was not suggesting changing the admin_ui_client, but instead only giving users the non-admin capability when using the admin ui. See the readme and contrast uaa_groups_admin and uaa_groups_user.

[jmcarp]

The admin ui does not use the CC API to retrieve information (or at least not much information), but only for non-read operations.

Do you mean "does not use the CC DB"?

Anyway, we're looking to drop the permissions of the uaa client so that a vulnerability in the admin-ui application code or credential leak wouldn't have as much impact. I understand that we can just hand out admin_ui.read permission to our users, but we're looking to go farther than that and prevent admin-ui from doing writes at all.

[rboykin]

@jmcarp For reading Cloud Controller data, the Admin UI goes direct to the CCDB. For write-type operations, the Admin UI uses the Cloud Controller REST API. UAA is similar. UAA reads are directed to the UAADB and writes are directed to the UAA REST API. Then you separately have reads from doppler and nats.

I suggest keeping dopper.firehose (for reading info on application instances and components stats) and openid and adding cloud_controller.global_auditor and remove the rest and see how well you fare. All of the other authorities are really for write access.