maint - add travis-ci configuration
Action Policy Authorization Plugin
This is a plugin that provides fine grained action level authorization for agents. Any MCollective agent plugins based on SimpleRPC can be restricted with authorization plugins like this one.
Installation
- Follow the plugin deployment guide, using the libdir copy method and placing the
actionpolicy.rbandactionpolicy.ddlfiles in theutildirectory.
Note that it is not currently possible to use the 'mco plugin package' command to package this plugin.
Configuration
There are three settings available for the actionpolicy plugin:
allow_unconfigured-- whether to allow requests to agents that do not have policy files configured. Boolean, with allowed values of0,1,y,n; values oftrueorfalseare not allowed. Defaults to0.enable_default-- whether to use a default policy file. Boolean, with allowed values of0,1,y,n; values oftrueorfalseare not allowed. Defaults to0.default_name-- the name of the default policy file, ifenable_defaultis set to1ory.
General authentication configuration options can be set in the server config file.
# Enables system wide rpc authorization
rpcauthorization = 1
# Sets the authorization provider to use the actionpolicy plugin
rpcauthprovider = action_policy
# Allow requests to agents without policies
plugin.actionpolicy.allow_unconfigured = 1
Default Policy Files
You can optionally have a default policy file that applies in the absence of an agent-specific policy file.
plugin.actionpolicy.enable_default = 1
plugin.actionpolicy.default_name = default
This allows you to create a policy file called default.policy which will be used unless a specific policy file exists. Note that if both
allow_unconfigured and enable_default are configured, all requests will go through the default policy, as enable_default takes precedence
over allow_unconfigured.
Usage
Policies are defined in files like <configdir>/policies/<agent>.policy
Example: Puppet agent policy file
# /etc/mcollective/policies/puppet.policy
policy default deny
allow cert=admin * * *
allow cert=acme-devs * customer=acme acme::devserver
allow cert=acme-devs enable disable status customer=acme *
# /etc/mcollective/policies/service.policy
policy default deny
allow cert=puppet-admins restart (puppet().enabled=false and environment=production) or environment=development
The above policy can be described as:
- Allow the
adminuser to invoke all Puppet actions on all servers. - Allow the
acme-devsuser to invoke all Puppet actions on machines with the fact customer=acme and the config class acme::devserver - Allow the
acme-devsuser to invoke the enable, disable and status actions on all other machines with fact customer=acme - Allow the
puppet-adminsuser to restart services at any time in development but in production only when Puppet has been disabled - All other commands get denied
Policy File Format
Policy files must have the following format:
- Any lines starting with
#are comments. - A single
policy default denyorpolicy default allowline is permitted; it can go anywhere in the file. This default policy will apply to any commands that don't match a specific rule. If you don't specify a default policy, the value of theplugin.actionpolicy.allow_unconfiguredsetting will be used as the default. - Any number of policy lines are permitted. These must be tab delimited lines with either four or five fields (the final field is optional) in the following order:
allowordeny- Caller ID --- must be either
*(always matches) or one caller ID string (see below) - Actions --- must be either
*(always matches) or a space-separated list of actions - Facts --- may be either
*(always matches), a space-separated list offact=valuepairs (matches if every listed fact matches), or any valid compound filter string - Classes --- may be completely absent (always matches),
*(always matches), a space-separated list of class names (matches if every listed class is present), or any valid compound filter string
Notes
- Like firewall rules, policy lines are processed in order --- ActionPolicy will allow or deny each request using the first rule that matches it. A policy line matches a request if every field after the allow/deny field matches.
- Policy lines must use hard tabs; editor features that convert tabs to spaces (like Vim's
expandtab) will result in non-functional policy lines. - Compound filter strings may match on facts, classes, and data plugins (MCollective 2.2.x or later). When using data plugins in action policies, you should avoid using slow ones, as this will impact the response times of agents, the client waiting time, etc.
Caller ID
Caller ID strings are always of the form <kind>=<value>, but both the kind and the value of the ID will depend on your security plugin. See your security plugin's documentation or code for details.
- The recommended SSL security plugin sets caller IDs of
cert=<NAME>, where<NAME>is the filename of the client's public key file (minus the.pemextension). So a request validated with thepuppet-admins.pempublic key file would be given a caller ID ofcert=puppet-admins. This kind of caller ID is cryptographically authenticated. - The PSK security plugin defaults to caller IDs of
uid=<UID>, where<UID>is the local UID of the client process. There are several other options available, which can be configured with theplugin.psk.callertypesetting. None of PSK's caller IDs are authenticated, and you should generally not be relying on authorization at all if you are using the PSK security plugin.
Hardcoding ActionPolicy Into a Specific Agent
Instead of using the site-wide authorization settings (as described above), you can also hardcode authorization plugins in your agents:
module MCollective::Agent
class Service<RPC::Agent
authorized_by :action_policy
# ...
end
end