+++ /dev/null
----
-layout: default
-title: Security Overview
-toc: false
----
-[broadcast paradigm]: /mcollective/reference/basic/messageflow.html
-[SimpleRPC]: /mcollective/simplerpc/
-[Authorization]: /mcollective/simplerpc/authorization.html
-[Auditing]: /mcollective/simplerpc/auditing.html
-[SSL security plugin]: /mcollective/reference/plugins/security_ssl.html
-[AES security plugin]: /mcollective/reference/plugins/security_aes.html
-[ActiveMQ Security]: /mcollective/reference/integration/activemq_security.html
-[ActiveMQ TLS]: http://activemq.apache.org/how-do-i-use-ssl.html
-[ActiveMQ SSL]: /mcollective/reference/integration/activemq_ssl.html
-[ActiveMQ STOMP]: http://activemq.apache.org/stomp.html
-[MCollective STOMP Connector]: /mcollective/reference/plugins/connector_stomp.html
-[ActionPolicy]: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AuthorizationActionPolicy
-[CentralAudit]: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AuditCentralRPC
-[Subcollectives]: reference/basic/subcollectives.html
-
-
-Due to the [broadcast paradigm] of mcollective security is a complex topic to
-discuss.
-
-This discussion will focus on strong SSL and AES+RSA based security plugins,
-these are not the default or only option but is currently the most secure.
-Both the [SSL security plugin] and [AES security plugin] provide strong caller
-identification, this is used by the [SimpleRPC] framework for [Authorization]
-and [Auditing].
-
-As every organisation has its own needs almost all aspects of the security
-system is pluggable. This is an overview of the current state of SSL based
-Authentication, Authorization and Auditing.
-
-<center><img src="/mcollective/images/mcollective-aaa.png"></center>
-
-The image above is a reference to use in the following pages, it shows a
-MCollective Setup and indicates the areas of discussion.
-
-The focus here is on ActiveMQ, some of the details and capabilities will
-differ between middleware systems.
-
-## Client Connections and Credentials
-
-Every STOMP connection has a username and password, this is used to gain basic
-access to the ActiveMQ system. We have a [ActiveMQ Security] sample setup
-documented.
-
-ActiveMQ can use LDAP and other security providers, details of this is out of
-scope here, you should use their documentation or the recently released book
-for details of that.
-
-### MCollective Protocol Security
-The main protocol used by MCollective keeps track of message creation time and
-a per message TTL. Messages that are older than the TTL are not accepted in
-future we will also do full replay protection.
-
-Both the AES+RSA and the SSL plugin secures these 2 properties cryptographically
-to make sure they are not tampered with.
-
-### The AES+RSA securith plugin
-When using the [AES security plugin] each user also gets a private and public
-key, like with SSH you need to ensure that the private keys remain private
-and not shared between users.
-
-This plugin can be configured to distribute public keys at the cost of some
-security, you can also manually distribute keys for the most secure setup.
-
-The public / private key pair is used to encrypt using AES and then to encrypt
-the key used during the AES phase using RSA. This provides encrypted payloads
-securing the reply strucutres.
-
-The client embeds a _caller_ structure in each request, if RSA decryption
-pass the rest of the MCollective agents, auditing etc can securely know who
-initiated a request.
-
-This caller is used later during Authorization and Auditing.
-
-The plugin secures the TTL and Message Time properties of the message making sure
-someone cannot intercept, tamper and replay these messages.
-
-This plugin comes with a significant setup, maintenance and performance overhead
-if all you need is to securely identify users use the SSL security plugin instead.
-
-### The SSL security plugin
-When using the [SSL security plugin] each user also gets a private and public
-certificate, like with SSH you need to ensure that the private keys remain
-private and not be shared between users. The public part needs to be
-distributed to all nodes.
-
-The private key is used to cryptographically sign each request being made by a
-client, later the public key will be used to validate the signature for
-authenticity.
-
-The client embeds a _caller_ structure in each request, if SSL signature
-validation pass the rest of the MCollective agents, auditing etc can securely
-know who initiated a request.
-
-This caller is used later during Authorization and Auditing.
-
-The plugin secures the TTL and Message Time properties of the message making sure
-someone cannot intercept, tamper and replay these messages.
-
-## Connection to Middleware
-
-By default the connections between Middleware and Nodes are not encrypted, just
-signed using the SSL keys above. [ActiveMQ supports TLS][ActiveMQ TLS] and the
-[stomp connector][ActiveMQ STOMP] supports this including full CA based
-certificate verification.
-
-The [MCollective STOMP Connector] also supports TLS, to configure MCollective
-to speak TLS to your nodes please follow our notes about [ActiveMQ SSL].
-
-Enabling TLS throughout will secure your connections from any kind of sniffing
-and Man in The Middle attacks.
-
-## Middleware Authorization and Authentication
-
-As mentioned above ActiveMQ has it's own users and every node and client
-authenticates using these.
-
-In addition to this you can on the middleware layer restrict access to topics,
-you can for example run a development and production collective on the same
-ActiveMQ infrastructure and allow your developers access to just the development
-collective using these controls. They are not very fine grained but should be a
-import step to configure for any real setup.
-
-We have a sample [ActiveMQ Security] setup documented that has this kind of
-control.
-
-By combining this topic level restrictions with [Subcollectives] you can create
-virtually isolated groups of nodes and give certain users access to only those
-subcollectives. Effectively partitioning out a subset of machines and giving
-secure access to just those.
-
-## Node connections and credentials
-
-As with the client the node needs a username and password to connect to the
-middleware and can also use TLS.
-
-It's not a problem if all the nodes share a username and password for the
-connection since generally nodes do not make new requests. You can enable
-registration features that will see your nodes make connections, you should
-restrict this as outlined in the previous section.
-
-When using the [SSL security plugin] all the nodes share a same SSL private
-and public key, all replies are signed using this key. It would not be
-impossible to add a per node certificate setup but I do not think this will
-add a significant level of security over what we have today.
-
-When using the [AES security plugin] nodes can have their own sets of keys
-and registration data can be secured. Replies are encrypted using the clients
-key and so only the client who made the request can read the replies.
-
-## SimpleRPC Authorization
-
-The RPC framework has a pluggable [Authorization] system, you can create very
-fine grain control over requests, for example using the [ActionPolicy] setup you
-can create a policy like this:
-
-{% highlight text %}
-policy default deny
-allow cert=rip * * *
-allow cert=john * customer=acme acme::devserver
-allow cert=john enable disable status customer=acme *
-{% endhighlight %}
-
-This applied to the service agent will allow different level of access to
-actions to different people. The caller id is based directly on the SSL Private
-Key in use and subject to validation on every node.
-
-As with other aspects of mcollective authorization is tied closely with meta
-data like facts and classes so you can use these to structure your authorization
-as can be seen above.
-
-You can provide your own authorization layers to fit your ogranizational needs,
-they can be specific to an agent or apply to the entire collective.
-
-## SimpleRPC Auditing
-
-The RPC layer can keep detailed [Auditing] records of every request received,
-the audit log shows the - SSL signature or RSA verified - caller, what agent, action
-and any arguments that was sent for every request.
-
-The audit layer is a plugin based system, we provide one that logs to a file on
-every node and there are [community plugins][CentralAudit] that keeps a centralized
-log both in log files and in MongoDB NoSQL database.
-
-Which to use depends on your usecase, obviously a centralized auditing system
-for thousands of nodes is very complex and will require a special plugin to be
-developed the community centralized audit log is ok for roughly 100 nodes or
-so.
Code Review / packages / precise / mcollective.git / blobdiff