github.com/rvaralda/deis@v1.4.1/docs/managing_deis/security_considerations.rst (about) 1 :title: Security considerations 2 :description: Security considerations for Deis. 3 4 .. _security_considerations: 5 6 Security considerations 7 ======================== 8 9 .. important:: 10 11 Deis is not suitable for multi-tenant environments 12 or hosting untrusted code. 13 14 A major goal of Deis is to be operationally secure and trusted by operations engineers in every deployed 15 environment. There are, however, two notable security-related considerations to be aware of 16 when deploying Deis. 17 18 19 Access to etcd 20 -------------- 21 Since all Deis configuration settings are stored in etcd (including passwords, keys, etc.), any access 22 to the etcd cluster compromises the security of the entire Deis installation. The various provision 23 scripts configure the etcd daemon to only listen on the private network interface, but any host or 24 container with access to the private network has full access to etcd. This also includes deployed 25 application containers, which cannot be trusted. 26 27 The planned approach is to configure iptables on the machines to prevent unauthorized access from 28 containers. Some requirements include: 29 30 * Containers must be able to access the outside world 31 * Containers must be able to access other containers 32 * Containers cannot access the CoreOS host (SSH, etcd, etc) 33 34 Further discussion about this approach is appreciated in GitHub issue `#986`_. 35 36 Application runtime segregation 37 ------------------------------- 38 Users of Deis often want to deploy their applications to separate environments 39 (commonly: development, staging, and production). Typically, physical network isolation isn't 40 the goal, but rather segregation of application environments - if a development app goes haywire, 41 it shouldn't affect production applications that are running in the cluster. 42 43 In Deis, deployed applications can be segregated by using the ```deis tags``` command. This 44 enables you to tag machines in your cluster with arbitrary metadata, then configure your applications 45 to be scheduled to machines which match the metadata. 46 47 For example, if some machines in your cluster are tagged with ```environment=production``` and some 48 with ```environment=staging```, you can configure an application to be deployed to the production 49 environment by using ```deis tags set environment=production```. Deis will pass this configuration 50 along to the scheduler, and your applications in different environments on running on separate 51 hardware. 52 53 .. _deis_on_public_clouds: 54 55 Running Deis on Public Clouds 56 ----------------------------- 57 If you are running on a public cloud without security group features, you will have to set up 58 security groups yourself through either ``iptables`` or a similar tool. The only ports that should 59 be exposed to the public are: 60 61 - 22: for remote SSH 62 - 80: for the routers 63 - 443: (optional) routers w/ SSL enabled 64 - 2222: for the builder 65 66 For providers that do not supply a security group feature, please try 67 `contrib/util/custom-firewall.sh`_. 68 69 .. note:: 70 If you need to add a new node to the cluster and you are using the custom firewall 71 `contrib/util/custom-firewall.sh`_ you must allow the access to the cluster running 72 the next command in each existing node: 73 74 .. code-block:: console 75 76 $ NEW_NODE="IP address" contrib/util/custom-firewall.sh 77 78 Router firewall 79 --------------- 80 The :ref:`Router` component includes a firewall to help thwart attacks. It can be enabled by running: 81 ``deisctl config router set firewall/enabled true``. For more information, see the `router README`_ 82 and :ref:`router_settings`. 83 84 .. _`#986`: https://github.com/deis/deis/issues/986 85 .. _`contrib/util/custom-firewall.sh`: https://github.com/deis/deis/blob/master/contrib/util/custom-firewall.sh 86 .. _`router README`: https://github.com/deis/deis/blob/master/router/README.md