Cloud Foundry Security: BOSH User Roles and the UAA Service
Deploying with BOSH
BOSH is a versatile tool that combines features for building releases, deploying, monitoring, updating, and otherwise managing life cycle of cloud software. In most cases, it is BOSH that controls and watches over the VMs where all Cloud Foundry components reside. Doesn’t it mean that BOSH operators have access to everything inside the deployment?
The answer is “It depends.” From this post, you will learn what information and access rights are available to BOSH operators and how to make BOSH and Cloud Foundry deployments more secure, using the UAA identity management service and BOSH’s own internal capabilities.
One user
Historically, BOSH only had one user with unlimited rights, but there are usually many operators in real production deployments. So, everyone was forced to use the same account to perform ongoing BOSH tasks. While you should trust your engineers, having only one account for everything creates certain risks:
- Any BOSH operator, regardless of their role and experience, has full control over hosts, applications, and environments.
- The environments sometimes contain sensitive data, such as endpoints and credentials to services (e.g., databases). BOSH operators have access to all this data, too.
- WIth one account, there is no way to tell who killed that router at 4 am today. In the logs, all actions appear to be performed by “admin.”
Preconfigured users
Starting with bosh-release v177+ (1.2999.0), the BOSH Director got a very simple built-in user management system that can authenticate operators. This is what most deployments use today. The list of operators can be defined in the manifest before the BOSH Director is deployed, like this:
properties:
director:
user_management:
provider: local
local:
users:
- {name: admin, password: <PASSWORD>}
- {name: hm, password: <PASSWORD>}
- {name: alex, password: <PASSWORD>}The possibility to have different admin accounts on one BOSH Director solved the who-killed-that-router issue, but all these accounts still have unlimited access to everything. There is a serious tradeoff though—adding new users/changing passwords causes BOSH to be re-deployed. That is bad news for many production deployments.
UAA for BOSH—”read-only” users
bosh-release v209+ (1.3088.0) finally gave us a way to limit operator rights by colocating the BOSH Director with its own UAA server. The UAA is the standard OAuth2 identity management service in Cloud Foundry. Like BOSH, it is sometimes used as a standalone authorization and authentication tool.
While you do not have to install the UAA service for BOSH, there are several important advantages of doing so:
- Users and rights can be added and removed through the UAA CLI without the need to re-deploy the BOSH Director.
- Users can be grouped and each group can have its own permissions.
- If there are several BOSH Directors, some users can be limited to access only one BOSH Director defined by its UUID.
- The UAA can be integrated with LDAP and other enterprise services.
On the downside, the permissions are far from being fine-grained. Only two roles are available:
- Admin. These accounts can access all resources and commands.
- Read-only. These accounts are limited to five CLI commands (see the table).
| bosh deployments | Shows the list of available deployments. |
| bosh releases | Shows the list of available releases. |
| bosh stemcells | Shows the list of available stemcells. |
| bosh vms | Lists all VMs in a deployment. |
| bosh tasks | Shows running tasks, including task descriptions without access to debug logs. |
Unauthenticated users may only use the “bosh status” command on a deployment to get information about the BOSH Director. You can find more details on how to set up a UAA server for BOSH here.
Summing it up, two roles is not much, but I believe it is a start. We can expect more UAA scopes to be added in BOSH soon—e.g., a way to allow or deny SSH to VMs.
Further reading
