The Clusternator server sits between the developer (client) and a cloud service provider like Amazon’s AWS.
In order for The Clusternator to assemble deployments it requires a number of permissions from the cloud service provider. Chances are that these permissions are too permissive for many people working on a given project.
By standing between the client and the cloud service provider, The Clusternator server limits what the end user can actually do with the cloud service provider.
In order for this to work The Clusternator needs to know about users, how to
authenticate them, and what authority they have. By default The Clusternator
starts with one user named
root. This user starts with a password provided
Each Clusternator user has an associated “Authority”. This authority determines what the user can/cannot do with The Clusternator server. The authorities guide has more information on authorities.
Each Clusternator user also has a password, or at least a salted-hashed password. More information can be found in the authentication section
Using an admin account, Clusternator users can be created with:
In order to keep things convenient for the clusternator end user, Clusternator
stores a little bit of information about the user. The Clusternator keeps this
~/.clusternator-config.json. This file should have its
permissions set to be user read only. Clusternator currently enforces this
restriction on write.
This file contains basic information about a user, but The Clusternator only
currently cares about the remote host, and the remote token. Both of which
are automatically managed by