Securing the server
Architecturally, the Razor server is a fairly standard web service, consisting of the web server itself (embedded in Torquebox) and the PostgreSQL database; as such, access to these components can be secured by the usual means of operating system security.
This is for compatibility with older deployments; a configuration file from the previous release will cause all RBAC to be disabled by default, and your server will work the same way as before.
To enable it, there are two settings in your config.yaml to make:
auth:
enabled: true # or false
config: shiro.ini # relative to the Razor root, or give an absolute path
Over the network, Razor exposes a RESTful API via HTTP; the API actually
consists of two parts: one, mapped underneath /api meant to control the
provisioning process to which administrators connect to create policies,
view node information, etc. the other, mapped underneath /svc for
communication between nodes and the server. By its very nature, the latter
can only be secured by restricting access to the /svc URL space on the
server at the network level.
The management API underneath /api is secured with
basic HTTP authentication.
Since the username and password are sent in the clear in HTTP headers, it
is crucially important that access to /api only happens via HTTPS. The
Torquebox documentation
has details on how to configure that.
Authentication information is configured in shiro.ini in the server's
root directory. The configuration format is described in the
Shiro documentation.
You can also find some example shiro configuration files for interfacing to external data sources such as Active Directory or a JDBC supported database in the distribution.
This documents the current authentication trees available in Razor, and their structure. This will be useful in setting up your own roles.
All the commands authorize in this structure:
commands:${name}:${subject}
name is the name of the command (eg: create-repo, delete-repo).
subject is the name of the main object (eg: create-repo:esxi55, delete-repo:esxi55).
When a command applies to multiple subjects, we will assert the permission required for all of them.
Queries authenticate in the structure:
query:${collection}:${name}
The one exception is the node logs:
query:${collection}:${name}:logs
collection is the name of the collection (eg: tags, brokers).
name is the name of the entity (eg: tags:virtual, brokers:puppet).
Reading node logs requires does not require reading data for the node, but reading data for the node implicitly grants reading logs.