Bureaucrats, confirmed, Administrators
4,558
edits
Changes
Jump to navigation
Jump to search
== Security == === Users and QB Provisioning ===Requirements:# A means for Ansible to connect (greg)# A means for Vagrant to conect (vagrant)# A control user to standardize documentation and procedures (qb)# A list of users to add to the QB Ansible is agentless and connects to hosts using ssh in order to execute all it's magic. See https://docs.ansible.com/ansible/intro_inventory.html#list-of-behavioral-inventory-parameters for the list of variables at issue when connecting to hosts. Root logins are not required (but you obviously need sudo to do anything important.) It's recommended to simply use <code>ssh-agent bash; ssh-add ~/.ssh/id_rsa</code> Although the 'ssh' in <code>ansible_ssh_user</code> is deprecated, you'll still find lots of usage of that variable. Thus, we need at least one key to initially connect to a host. We also want to provision the QB such that there is a "control user" (qb) that our documentation can refer to. We also want to be able to provision the QB with a list of users who may be members of the client organization who will want command-line access to the QB. The precedence rules for the <code>user</code> parameter are<ref>https://github.com/mitchellh/vagrant/pull/5044</ref>:# <code>ansible_ssh_user</code> (now known as <code>ansible_user</code>) in inventory or as ''extra_vars''# <code>remote_user</code> or <code>user</code> YAML attributes in a playbook file# <code>-u (--user)</code> ansible-playbook argument# <code>ANSIBLE_REMOTE_USER</code> environment variable# <code>remote_user</code> parameter in <code>ansible.cfg</code> file# and last but not least, it will default to the username of the current user (aka $USER) Ansible has an [https://docs.ansible.com/ansible/authorized_key_module.html "Authorized Key" module] which is used for adding or removing keys. There is also the User module For the list of users, we will maintain a folder/file tree where we can add the public keys to both add and revoke access to the QB. Something like this <ref>https://brokenbad.com/better-handling-of-public-ssh-keys-using-ansible/</ref><source lang="yaml">tasks:- name: Manage Authorized Keys | Allow with_fileglob: pubkeys/allow/* - name: Manage Authorized Keys | Deny with_fileglob: pubkeys/deny/*</source>But the problem with this code is that it does not iterate over the names of users (there is a single 'targetUser' for each run). It would be better to match the name of each user with the key for each user (e.g. pair 'bob' with /pubkeys/allow/bob.id_rsa.pub') In launch.yml we use the '''digital_ocean:''' module (https://github.com/ansible/ansible-modules-core/blob/devel/cloud/digital_ocean/digital_ocean.py) which has the <nowiki>{{ssh_pub_key}}</nowiki> option/argument which the value should be the public SSH key you want to add to your account. Note the '''digital_ocean:''' module has two ''command'' options (droplet|ssh) to indicate whether you are deploying a droplet, or deploying a key. Correspondingly, the ''name'' option is either the name of the droplet, or the name of the key you are deploying. By default, the module ''waits'' for the server to be running and we double the ''wait_timeout'' to 600 seconds <ref>Two environment variables can be used, DO_API_KEY and DO_API_TOKEN</ref> With tasks/security.yml we use the '''user:''' module and <nowiki>{{ssh_user}}</nowiki> which is defined in vars.yml as <nowiki>"{{ lookup('env', 'USER') }}"</nowiki> to create the home directory for the user running ansible (greg) and using his id_rsa.... We eliminated the redundant <nowiki>{{ssh_pub_key}}</nowiki> and <nowiki>{{do_ssh_pub_key}}</nowiki> etc. === Security and the OS ===The QB hardens the Operating System level to provide security at the box/node/network level.# Restrict SSH logins to use certificates only# Deny root logins# Install and configure a firewall (UFW)# Install and configure fail2ban# Automatically run OS and package security updates with <code>[[Unattended upgrades|unattended-upgrades]]</code> <ref>In a typical MONTH there are dozens for security updates that should be applied. These need to happen automatically.<blockquote> Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-34-generic x86_64) * Documentation: https://help.ubuntu.com/ System information as of Wed Sep 21 16:15:53 UTC 2016 System load: 0.0 Processes: 129 Usage of /: 74.7% of 39.25GB Users logged in: 0 Memory usage: 27% IP address for eth0: 198.199.121.96 Swap usage: 0% IP address for eth1: 10.136.17.129 Graph this data and manage this system at: https://landscape.canonical.com/ 42 packages can be updated. <span style="color:red;">30 updates are security updates.</span></blockquote></ref> === Security and the Webserver ===The QB is designed to use '''HTTPS everywhere''' (not [https://www.eff.org/https-everywhere the extension], but rather the concept). With that in mind, we're provisioning TLS Certificates using the [https://certbot.eff.org/ Certbot] client of the [https://letsencrypt.org/ letsencrypt] project. There is an 'extras' module for letsencrypt https://docs.ansible.com/ansible/letsencrypt_module.html Although we can automate certificates on a live server (one that has an A record in DNS), we need a manual step to prove ownership of any server that is not public. The manual step is to create a TXT record in the public DNS for the domain in question.<ref>https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-7.4</ref>{{AI}} Finish the implementation of not just installation of the Certbot, but also the ability to create and verify private hosts {{ReferencesDeprecated}}
Special:Badtitle/NS100:QualityBox/security (view source)
Revision as of 16:09, 6 November 2016
, 16:09, 6 November 2016Replaced content with "{{Deprecated}}"
