WIP: Enabling ACLs on clouds, credentials, etc

juju
1

Juju is currently allowing users to add multiple cloud definitions to a controller. We want to allow users to share the cloud definition with other users. The prime case is to add a k8s definition to the controller and then not make each other person add that as well.

Along with sharing cloud definitions with others is the idea of sharing use of cloud credentials. In this way teams could share cloud credentials without requiring passing the actual values around to folks.

With the growing complexity of sharable entities in Juju we propose to add a series of grant commands that are specific and explicit in their use.

juju grant(-model) USER PERMISSION [ENTITY]...
juju grant-controller
juju grant-cloud
juju grant-credential

Access can be granted to more than one entity at a time and the PERMISSIONS are standard across types of entities. The goal is to use a persistent set of roles for the PERMISSIONS to help standardize what can be set on any given entity in Juju.

  • admin - The access granted includes permission to remove and update permissions on the entity
  • write - The access granted includes the ability to change the entity
  • read - The access granted includes the ability to read information about the entity

Special PERMISSIONS

  • login - grant-controller includes a login PERMISSION that enables users to be able to login into the controller and can be revoked to remove users without breaking things like running models.

This breaks down into the following:

Model

The grant command turns into defaulting to a grant-model command in order to retain backward compatibility. There is also the future looking grant-model in order to create scripts more future ready.

Admin

  • is able to remove the model
  • is able to set model config
  • is able to add/remove other users from the model
  • can make any changes to the model including deployment, resources, etc.

Write

  • can make any changes to the model including deployment, resources, etc.

Read

  • Is able to view status and other read-only information from the model (think auditor)

Cloud

Admin

  • Is able to remove the cloud definition from the controller
  • is able to change the cloud definition including api urls
  • is able to update permissions on the cloud

Write

  • is able to change the cloud definition including api urls

Read

  • is able to use the cloud definition to create new models in the user’s namespace.

Credential

Admin

  • Is able to remove the credential definition from the controller
  • is able to change the credential definition including secrets
  • is able to update permissions on the credential

Write

  • is able to change the credential definition including secrets

Read

  • is able to use the credential definition to create new models in the user’s namespace.

Controller

Permissions to the controller also match up to the controller model.

Admin

  • is able to destroy the controller
  • is able to update permissions on the controller
  • is able to make changes to the controller model
  • is able to make changes to the controller config

Write

  • is able to make changes to the controller model
  • is able to make changes to the controller config

Read

  • Is able to view status and other read-only information from the controller (think auditor)

login

  • the user is able to login to the controller and gain access to their other permissions. Removing login disables an account without deleting it causing ownership issues/etc.