website/security.md

   1 ---
   2 layout: default
   3 title: Security Overview
   4 toc: false
   5 ---
   6 [broadcast paradigm]: /mcollective/reference/basic/messageflow.html
   7 [SimpleRPC]: /mcollective/simplerpc/
   8 [Authorization]: /mcollective/simplerpc/authorization.html
   9 [Auditing]: /mcollective/simplerpc/auditing.html
  10 [SSL security plugin]: /mcollective/reference/plugins/security_ssl.html
  11 [AES security plugin]: /mcollective/reference/plugins/security_aes.html
  12 [ActiveMQ Security]: /mcollective/reference/integration/activemq_security.html
  13 [ActiveMQ TLS]: http://activemq.apache.org/how-do-i-use-ssl.html
  14 [ActiveMQ SSL]: /mcollective/reference/integration/activemq_ssl.html
  15 [ActiveMQ STOMP]: http://activemq.apache.org/stomp.html
  16 [MCollective STOMP Connector]: /mcollective/reference/plugins/connector_stomp.html
  17 [ActionPolicy]: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AuthorizationActionPolicy
  18 [CentralAudit]: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AuditCentralRPC
  19 [Subcollectives]: reference/basic/subcollectives.html
  20
  21
  22 Due to the [broadcast paradigm] of mcollective security is a complex topic to
  23 discuss.
  24
  25 This discussion will focus on strong SSL and AES+RSA based security plugins,
  26 these are not the default or only option but is currently the most secure.
  27 Both the [SSL security plugin] and [AES security plugin] provide strong caller
  28 identification, this is used by the [SimpleRPC] framework for [Authorization]
  29 and [Auditing].
  30
  31 As every organisation has its own needs almost all aspects of the security
  32 system is pluggable.  This is an overview of the current state of SSL based
  33 Authentication, Authorization and Auditing.
  34
  35 <center><img src="/mcollective/images/mcollective-aaa.png"></center>
  36
  37 The image above is a reference to use in the following pages, it shows a
  38 MCollective Setup and indicates the areas of discussion.
  39
  40 The focus here is on ActiveMQ, some of the details and capabilities will
  41 differ between middleware systems.
  42
  43 ## Client Connections and Credentials
  44
  45 Every STOMP connection has a username and password, this is used to gain basic
  46 access to the ActiveMQ system.  We have a [ActiveMQ Security] sample setup
  47 documented.
  48
  49 ActiveMQ can use LDAP and other security providers, details of this is out of
  50 scope here, you should use their documentation or the recently released book
  51 for details of that.
  52
  53 ### MCollective Protocol Security
  54 The main protocol used by MCollective keeps track of message creation time and
  55 a per message TTL.  Messages that are older than the TTL are not accepted in
  56 future we will also do full replay protection.
  57
  58 Both the AES+RSA and the SSL plugin secures these 2 properties cryptographically
  59 to make sure they are not tampered with.
  60
  61 ### The AES+RSA securith plugin
  62 When using the [AES security plugin] each user also gets a private and public
  63 key, like with SSH you need to ensure that the private keys remain private
  64 and not shared between users.
  65
  66 This plugin can be configured to distribute public keys at the cost of some
  67 security, you can also manually distribute keys for the most secure setup.
  68
  69 The public / private key pair is used to encrypt using AES and then to encrypt
  70 the key used during the AES phase using RSA.  This provides encrypted payloads
  71 securing the reply strucutres.
  72
  73 The client embeds a _caller_ structure in each request, if RSA decryption
  74 pass the rest of the MCollective agents, auditing etc can securely know who
  75 initiated a request.
  76
  77 This caller is used later during Authorization and Auditing.
  78
  79 The plugin secures the TTL and Message Time properties of the message making sure
  80 someone cannot intercept, tamper and replay these messages.
  81
  82 This plugin comes with a significant setup, maintenance and performance overhead
  83 if all you need is to securely identify users use the SSL security plugin instead.
  84
  85 ### The SSL security plugin
  86 When using the [SSL security plugin] each user also gets a private and public
  87 certificate, like with SSH you need to ensure that the private keys remain
  88 private and not be shared between users.  The public part needs to be
  89 distributed to all nodes.
  90
  91 The private key is used to cryptographically sign each request being made by a
  92 client, later the public key will be used to validate the signature for
  93 authenticity.
  94
  95 The client embeds a _caller_ structure in each request, if SSL signature
  96 validation pass the rest of the MCollective agents, auditing etc can securely
  97 know who initiated a request.
  98
  99 This caller is used later during Authorization and Auditing.
 100
 101 The plugin secures the TTL and Message Time properties of the message making sure
 102 someone cannot intercept, tamper and replay these messages.
 103
 104 ## Connection to Middleware
 105
 106 By default the connections between Middleware and Nodes are not encrypted, just
 107 signed using the SSL keys above.  [ActiveMQ supports TLS][ActiveMQ TLS] and the
 108 [stomp connector][ActiveMQ STOMP] supports this including full CA based
 109 certificate verification.
 110
 111 The [MCollective STOMP Connector] also supports TLS, to configure MCollective
 112 to speak TLS to your nodes please follow our notes about [ActiveMQ SSL].
 113
 114 Enabling TLS throughout will secure your connections from any kind of sniffing
 115 and Man in The Middle attacks.
 116
 117 ## Middleware Authorization and Authentication
 118
 119 As mentioned above ActiveMQ has it's own users and every node and client
 120 authenticates using these.
 121
 122 In addition to this you can on the middleware layer restrict access to topics,
 123 you can for example run a development and production collective on the same
 124 ActiveMQ infrastructure and allow your developers access to just the development
 125 collective using these controls.  They are not very fine grained but should be a
 126 import step to configure for any real setup.
 127
 128 We have a sample [ActiveMQ Security] setup documented that has this kind of
 129 control.
 130
 131 By combining this topic level restrictions with [Subcollectives] you can create
 132 virtually isolated groups of nodes and give certain users access to only those
 133 subcollectives.  Effectively partitioning out a subset of machines and giving
 134 secure access to just those.
 135
 136 ## Node connections and credentials
 137
 138 As with the client the node needs a username and password to connect to the
 139 middleware and can also use TLS.
 140
 141 It's not a problem if all the nodes share a username and password for the
 142 connection since generally nodes do not make new requests.  You can enable
 143 registration features that will see your nodes make connections, you should
 144 restrict this as outlined in the previous section.
 145
 146 When using the [SSL security plugin] all the nodes share a same SSL private
 147 and public key, all replies are signed using this key.  It would not be
 148 impossible to add a per node certificate setup but I do not think this will
 149 add a significant level of security over what we have today.
 150
 151 When using the [AES security plugin] nodes can have their own sets of keys
 152 and registration data can be secured.  Replies are encrypted using the clients
 153 key and so only the client who made the request can read the replies.
 154
 155 ## SimpleRPC Authorization
 156
 157 The RPC framework has a pluggable [Authorization] system, you can create very
 158 fine grain control over requests, for example using the [ActionPolicy] setup you
 159 can create a policy like this:
 160
 161 {% highlight text %}
 162 policy default deny
 163 allow   cert=rip      *                       *                *
 164 allow   cert=john     *                       customer=acme    acme::devserver
 165 allow   cert=john     enable disable status   customer=acme    *
 166 {% endhighlight %}
 167
 168 This applied to the service agent will allow different level of access to
 169 actions to different people.  The caller id is based directly on the SSL Private
 170 Key in use and subject to validation on every node.
 171
 172 As with other aspects of mcollective authorization is tied closely with meta
 173 data like facts and classes so you can use these to structure your authorization
 174 as can be seen above.
 175
 176 You can provide your own authorization layers to fit your ogranizational needs,
 177 they can be specific to an agent or apply to the entire collective.
 178
 179 ## SimpleRPC Auditing
 180
 181 The RPC layer can keep detailed [Auditing] records of every request received,
 182 the audit log shows the - SSL signature or RSA verified - caller, what agent, action
 183 and any arguments that was sent for every request.
 184
 185 The audit layer is a plugin based system, we provide one that logs to a file on
 186 every node and there are [community plugins][CentralAudit] that keeps a centralized
 187 log both in log files and in MongoDB NoSQL database.
 188
 189 Which to use depends on your usecase, obviously a centralized auditing system
 190 for thousands of nodes is very complex and will require a special plugin to be
 191 developed the community centralized audit log is ok for roughly 100 nodes or
 192 so.