You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

98 lines
4.0 KiB

7 years ago
  1. Hashicorp Vault Role
  2. ====================
  3. The vault role have been retired from the main playbook.
  4. This role probably requires a LOT of changes in order to work again
  5. Overview
  6. --------
  7. The Vault role is a two-step process:
  8. 1. Bootstrap
  9. You cannot start your certificate management service securely with SSL (and
  10. the datastore behind it) without having the certificates in-hand already. This
  11. presents an unfortunate chicken and egg scenario, with one requiring the other.
  12. To solve for this, the Bootstrap step was added.
  13. This step spins up a temporary instance of Vault to issue certificates for
  14. Vault itself. It then leaves the temporary instance running, so that the Etcd
  15. role can generate certs for itself as well. Eventually, this may be improved
  16. to allow alternate backends (such as Consul), but currently the tasks are
  17. hardcoded to only create a Vault role for Etcd.
  18. 1. Cluster
  19. This step is where the long-term Vault cluster is started and configured. Its
  20. first task, is to stop any temporary instances of Vault, to free the port for
  21. the long-term. At the end of this task, the entire Vault cluster should be up
  22. and ready to go.
  23. Keys to the Kingdom
  24. -------------------
  25. The two most important security pieces of Vault are the ``root_token``
  26. and ``unsealing_keys``. Both of these values are given exactly once, during
  27. the initialization of the Vault cluster. For convenience, they are saved
  28. to the ``vault_secret_dir`` (default: /etc/vault/secrets) of every host in the
  29. vault group.
  30. It is *highly* recommended that these secrets are removed from the servers after
  31. your cluster has been deployed, and kept in a safe location of your choosing.
  32. Naturally, the seriousness of the situation depends on what you're doing with
  33. your Kubespray cluster, but with these secrets, an attacker will have the ability
  34. to authenticate to almost everything in Kubernetes and decode all private
  35. (HTTPS) traffic on your network signed by Vault certificates.
  36. For even greater security, you may want to remove and store elsewhere any
  37. CA keys generated as well (e.g. /etc/vault/ssl/ca-key.pem).
  38. Vault by default encrypts all traffic to and from the datastore backend, all
  39. resting data, and uses TLS for its TCP listener. It is recommended that you
  40. do not change the Vault config to disable TLS, unless you absolutely have to.
  41. Usage
  42. -----
  43. To get the Vault role running, you must to do two things at a minimum:
  44. 1. Assign the ``vault`` group to at least 1 node in your inventory
  45. 1. Change ``cert_management`` to be ``vault`` instead of ``script``
  46. Nothing else is required, but customization is possible. Check
  47. ``roles/vault/defaults/main.yml`` for the different variables that can be
  48. overridden, most common being ``vault_config``, ``vault_port``, and
  49. ``vault_deployment_type``.
  50. As a result of the Vault role will be create separated Root CA for `etcd`,
  51. `kubernetes` and `vault`. Also, if you intend to use a Root or Intermediate CA
  52. generated elsewhere, you'll need to copy the certificate and key to the hosts in the vault group prior to running the vault role. By default, they'll be located at:
  53. * vault:
  54. * ``/etc/vault/ssl/ca.pem``
  55. * ``/etc/vault/ssl/ca-key.pem``
  56. * etcd:
  57. * ``/etc/ssl/etcd/ssl/ca.pem``
  58. * ``/etc/ssl/etcd/ssl/ca-key.pem``
  59. * kubernetes:
  60. * ``/etc/kubernetes/ssl/ca.pem``
  61. * ``/etc/kubernetes/ssl/ca-key.pem``
  62. Additional Notes:
  63. * ``groups.vault|first`` is considered the source of truth for Vault variables
  64. * ``vault_leader_url`` is used as pointer for the current running Vault
  65. * Each service should have its own role and credentials. Currently those
  66. credentials are saved to ``/etc/vault/roles/<role>/``. The service will
  67. need to read in those credentials, if they want to interact with Vault.
  68. Potential Work
  69. --------------
  70. * Change the Vault role to not run certain tasks when ``root_token`` and
  71. ``unseal_keys`` are not present. Alternatively, allow user input for these
  72. values when missing.
  73. * Add the ability to start temp Vault with Host or Docker
  74. * Add a dynamic way to change out the backend role creation during Bootstrap,
  75. so other services can be used (such as Consul)