copied docs

aws-accountsetup/index.rst

@@ -0,0 +1,53 @@
+===================
+AWS - Account Setup
+===================
+
+
+**Our AWS VPC Account Setup**
+
+
+.. ATTENTION::
+   Nearly everything is public. Services have to communicate over secure transport layer (HTTPS, SSL, SSH etc.)
+
+   Take care of your **Security Groups** in the public DMZ subnets.
+
+
+Only the public "DMZ" subnets have a direct connection to the internet.  The communication with other teams is only possible over the internet.
+Instances in a Private subnet can only talk to the internet via a **NAT-Instance**.
+The **NAT-instances** are in multiple Availbilty Zones (AZ), therefore every **PRIVATE SUBNET** can communicate to the Internet.
+
+If a Team want to talk to another Team they have to do this from the **PRIVATE SUBNET** over the Internet.
+Because only the private subnet has the Elastic IP's for outgoing traffic.
+The other Team can grant access to this IP's, for example in a Security Group of a ELB (Elastic Loadbalancer)
+
+**Main Points**
+
+   * Communication between teams goes over the **public network**
+   * NAT-Instances get **Elastic IP's**
+      * every team got 3 Public IP's to communicate to the Internet
+      * Other Teams can use these IP's to grant access to there Instances (mostly **ELB**)
+   * We will setup 2 different types of subnets **DMZ** and **Internal**
+   * **Every Team** got the same default Network **172.31.0.0/16**
+      * therefore no **VPN-Tunnel** or **VPC-Peering** is possible between teams
+   * Instances in **Internal** can only be accessed through a SSH bastion host
+
+.. image:: images/AWS-Public-Account-Setup.png
+
+
+
+**setup process**
+
+
+
+The following pages describe our Amazon Web Services initial setup.
+This is only for a whole new AWS Account (a new account for a Team or Service).
+
+.. toctree::
+   :maxdepth: 1
+
+   create_aws_account
+   manual-setup
+   automatic-setup
+
+
+

aws/best-practice.rst

@@ -0,0 +1,11 @@
+==============
+Best Practices
+==============
+
+Some best practices for AWS usage:
+
+* Use `AWS Minion`_ or `Simple Stack`_ for application deployment
+* Use IAM roles and instance profiles to grant access to AWS resources without credentials
+
+.. _AWS Minion: http://aws-minion.readthedocs.org/
+.. _Simple Stack: https://github.com/zalando/simplestack

aws/index.rst

@@ -0,0 +1,25 @@
+===================
+Amazon Web Services
+===================
+
+General guiding principles:
+
+* Team is the main entity for ownership and security boundaries.
+* Interactions between teams (e.g. service calls) should involve the minimum friction possible.
+* Sensitive data (e.g. customer data) must only be accessible by authorized personnel.
+* All deployed software components must have sane default security settings.
+
+Every team gets their own AWS account with defacto-administrator access to all resources in it:
+
+* This ensures that only team members can manage their AWS resources.
+* Team members use the AWS infrastructure by authenticating via SAML
+* Teams are fully responsible for all data that is processed in their AWS account.
+* All running applications (exposing HTTPS) are automatically available to other teams.
+
+.. toctree::
+   :maxdepth: 1
+
+   saml
+   zalando-ami
+   best-practice
+   audit

aws/zalando-ami.rst

@@ -0,0 +1,204 @@
+===========
+Zalando AMI
+===========
+
+We enforce the usage of the official Zalando AMI in order to fulfill our auditing requirements. We have to bridge the
+gap between freedom and compliance.
+
+As we want to foster immutable (and therefore deterministic and reproducible) deployments, we want to encourage the use
+of Docker (and similar deployment technologies). The Zalando AMI is capable of starting a Docker container on boot. This
+will enable teams to deploy 'what they want' as long as they package it in a Docker image. The server will be
+set up to have an optimal configuration including managed SSH access, audit logging, log collection, monitoring and
+reviewed security additions.
+
+---------------------
+Using the Zalando AMI
+---------------------
+
+There is currently no internal tooling but you can find the Zalando AMIs in your EC2 UI. They are maintained by the
+Platform team and regularly updated with the newest security fixes and configuration improvements.
+
+.. NOTE::
+   The process of updating the AMI is not established nor discussed yet!
+
+How to configure the AMI
+++++++++++++++++++++++++
+
+The Zalando AMI uses the official cloud-init project to receive user configuration. Different to the standard, you can
+not use the normal user data mimetypes (no #cloud-config, shell scripts, file uploads, URL lists, ...) but only our own
+configuration format::
+
+   #zalando-ami-config
+
+   application_name: my-nginx-test-app
+
+   runtime: Docker
+   source: dockerfiles/nginx:latest
+
+   ports:
+     80: 80
+     443: 443
+
+   environment:
+     STAGE: production
+
+   capabilities_add:
+     - NET_BIND_SERVICE
+   capabilities_drop:
+     - NET_ADMIN
+
+   root: false
+
+   mounts:
+     /var/lib/zookeeper-logs:
+       devices:
+         - /dev/sdb
+       setup: true
+
+     /var/lib/zookeeper-data:
+       devices:
+         - /dev/sdc
+         - /dev/sdd
+       raid_mode: 0
+       setup: true
+
+   notify_cfn:
+     stack: pharos
+     resource: WebServerGroup
+
+   ssh_ports:
+     - 22
+
+Provide this configuration as your user-data during launch of your EC2 instance.
+
+application_name:
+-----------------
+
+**(required)**
+
+The well-known, registered application identifier/name. Examples: "order-engine", "eventlog-service", ..
+
+runtime:
+--------
+
+**(required)**
+
+What kind of deployment artifact you are using. Currently supported:
+
+* Docker
+
+.. NOTE::
+   We plan to integrate CoreOS's Rocket as a runtime for experimental use soon.
+
+source:
+-------
+
+**(required)**
+
+The source, the configured runtime uses to fetch your delpoyment artifact. For Docker, this is the Docker image.
+
+ports:
+------
+
+**(optional, default: no ports open)**
+
+A map of all ports that have to be opened from the container. The key is the original port in your container and its
+value is the public server port to open.
+
+environment:
+------------
+
+**(optional)**
+
+A map of environment variables to set.
+
+capabilities_add:
+-----------------
+
+**(optional)**
+
+A list of capabilities to add to the execution (without the CAP_ prefix). See
+http://man7.org/linux/man-pages/man7/capabilities.7.html for available capabilities.
+
+capabilities_drop:
+------------------
+
+**(optional)**
+
+A list of capabilities to drop of the execution (without the CAP_ prefix). See
+http://man7.org/linux/man-pages/man7/capabilities.7.html for available capabilities.
+
+root:
+-----
+
+**(optional, default: false)**
+
+Specifies, if the container has to run as root. By default, containers run as an unprivileged user. See the
+**capabilities_add** and prefer it always. This is only the last resort.
+
+mounts:
+-------
+
+**(optional)**
+
+A map of mount targets and device configurations. A device configuration has **device** to reference the root device
+node and a **setup** flag if the device should be partitioned and formatted no boot (of not, the AMI expects and mounts
+partition 1 from the device).
+
+notify_cfn:
+-----------
+
+**(optional)**
+
+Will send cloud formation the boot result if specified. If you specify it, you have to provide the **stack** name and
+the stack **resource** with which this server was booted. This helps cloud formation to know, if starting you server
+worked or not (else, it will run into a timeout, waiting for notifications to arrive).
+
+If you would use the example stack
+http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/example-templates-autoscaling.html
+the resource name would be **WebServerGroup**.
+
+ssh_ports:
+----------
+
+**(optional, default: 22)**
+
+List of SSH server ports. This option allows using alternative TCP ports for the OpenSSH server.
+This is useful if an application (runtime container) wants to use the default SSH port.
+
+AMI internals
++++++++++++++
+
+This section gives you an overview of customization, the Zalando AMI contains on top of the Ubuntu Cloud Images.
+
+Hardening
+---------
+
+TODO
+
+* Kernel grsecurity, PAX?
+* Resrictive file permissions (no unused SUID bins etc)
+* Unused users and groups removed
+* Unused daemons disabled
+* Zalando CA preinstalled
+* Weak crypto algorithms disabled (SSH)
+* Unused packages removed
+* No passwords for users
+* iptables preconfigured with only specified ports + ssh open
+* hardened network settings (sysctl)
+* disabled IPv6 (not possible in AWS anyways)
+
+Auditing & Logs
+---------------
+
+TODO
+
+* auditd logs all access
+* all logs, including application logs (docker logs) are streamed to central logging service and rotated
+
+Managed SSH access
+------------------
+
+SSH access is managed with the SSH access granting service. The AMI is set up to have automatic integration. Your
+SSH key pair choice on AWS will be ignored - temporary access can only be gained via the granting service. All user
+actions are logged for auditing reasons.