One place for hosting & domains

      Vault

      How To Securely Manage Secrets with HashiCorp Vault on Ubuntu 20.04


      Introduction

      Vault is an open-source tool that provides a secure, reliable way to store and distribute secrets like API keys, access tokens, and passwords. Software like Vault can be critically important when deploying applications that require the use of secrets or sensitive data.

      In this tutorial, you will:

      • Install Vault and configure it as a system service
      • Initialize an encrypted on-disk data store
      • Store and retrieve a sensitive value securely over TLS

      With some additional policies in place, you’ll be able to use Vault to securely manage sensitive data for your various applications and tools.

      As with any service that manages sensitive information, you should consider reading additional documentation regarding Vault’s deployment best practices before using it in a production-like environment. For example, Vault’s production hardening guide covers topics such as policies, root tokens, and auditing.

      Prerequisites

      Before you begin this guide you’ll need the following:

      Note: Vault generates a self-signed TLS certificate when you install the package for the first time. If you do not have a domain name or TLS certificate to use with Vault but would like to follow the steps in this tutorial, you can skip TLS verification by adding the -tls-skip-verify flag to the commands in this tutorial, or by defining the VAULT_SKIP_VERIFY environment variable.

      This option is only suitable for experimenting with Vault and should not be used in a production environment.

      Step 1 — Installing Vault

      HashiCorp provides Vault as a typical Debian/Ubuntu package, so we’ll go through the normal steps of adding their package repository to our server’s list of package sources:

      First, add Hashicorp’s GPG key to your package manager, so that your system trusts their package repositories:

      • curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -

      Then add the repository itself to your list of package sources, so it’ll be checked for regular updates:

      • sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

      Then install the package:

      You can now use the vault command. Try checking Vault’s version to make sure it works.

      Output

      Vault v1.8.5 (647eccfe0bd5817bdd8628f3c3171402dfc8a8fc)

      The Vault executable is installed on your server, so the next step is to configure it to run as a system service.

      Step 2 — Configuring Vault

      Installing the Vault package automatically creates a vaultvault user on your system and sets up a system service for running Vault in the background. We need to make a couple of changes to its default configuration in order to use the HTTPS certificates generated by Let’s Encrypt.

      Note: In this tutorial and by default, Vault uses the filesystem backend to store encrypted secrets on the local filesystem at /opt/vault. This is suitable for local or single-server deployments that do not need to be replicated. Other Vault backends, such as the Consul backend, will store encrypted secrets at rest within a distributed key/value store.

      Vault’s default configuration is stored in /etc/vault.d/vault.hcl. You’ll use this file to control various options in Vault, such as where encrypted secrets are stored.

      Open vault.hcl using nano or your favorite text editor.

      • sudo nano /etc/vault.d/vault.hcl

      Find the listener "tcp" section of the file that contains this block. If you are using nano, you can press Ctrl+W then enter listener “tcp” to find that line directly:

      /etc/vault.hcl

      listener "tcp" {
        address       = "0.0.0.0:8200"
        tls_cert_file = "/opt/vault/tls/tls.crt"
        tls_key_file  = "/opt/vault/tls/tls.key"
      ...
      }
      

      Edit the tls_cert_file and tls_key_file lines to point to your Let’s Encrypt certificate and key files. Don’t forget to substitute in your own domain name in place of the highlighted your_domain part of each line.

      /etc/vault.hcl

      listener "tcp" {
      ...
        tls_cert_file = "/etc/letsencrypt/live/your_domain/fullchain.pem"
        tls_key_file = "/etc/letsencrypt/live/your_domain/privkey.pem"
      }
      

      Note: You should also change address = "0.0.0.0:8200" to address = “127.0.0.1:8200” to prevent external connections to this server for now. 127.0.0.1 is a reserved address for localhost only. This is to ensure that the service is not exposed to the public internet before it has been properly secured. You can update this later, but for now, this configuration change will let us use the vault command and correctly resolve the HTTPS-secured domain name.

      Save and close the file. If you are using nano, press Ctrl+X, then Y when prompted to save the file, and Enter to confirm.

      Next, the vault system user also needs permission to read these certificates. By default, these certificates and private keys are only accessible by root. To make these available securely, we’ll create a special group called pki to access these files. We will create the group and then add the vault user to it.

      Update the permissions on the two directories in the /etc/letsencrypt directory to allow members of the pki group to read the contents.

      • sudo chgrp pki /etc/letsencrypt/archive
      • sudo chgrp pki /etc/letsencrypt/live
      • sudo chmod g+rx /etc/letsencrypt/archive
      • sudo chmod g+rx /etc/letsencrypt/live

      Then add the vault user to the pki group. This will grant Vault access to the certificates so that it can serve requests securely over HTTPS.

      • sudo usermod -a -G pki vault

      As a final step for convenience, add a rule in /etc/hosts to direct requests to Vault to localhost.

      Replace your_domain in the following command with the domain you acquired the Let’s Encrypt certificate for:

      • echo 127.0.0.1 your_domain.com | sudo tee -a /etc/hosts

      This command appends the line 127.0.0.1 your_domain.com to /etc/hosts so that any HTTP requests that you make on your Vault server to your_domain.com ignore DNS and are sent to localhost directly.

      With the Vault service set up and the Vault configuration file complete, we’re now ready to start Vault and initialize the secret store.

      Step 3 — Initializing Vault

      When you first start Vault, it will be uninitialized, which means that it isn’t ready to receive and store data. In this section of the tutorial, you will start the Vault server, and then initialize it with a set of secret keys that will be used to unseal (open) Vault’s secret stores.

      The first time you start Vault, the backend that actually stores the encrypted secrets is uninitialized, too. Start the Vault system service to initialize the backend and start running Vault itself.

      • sudo systemctl start vault.service

      You can run a quick check to confirm the service has started successfully.

      • sudo systemctl status vault.service

      You should receive output similar to the following:

      Output

      ● vault.service - "HashiCorp Vault - A tool for managing secrets" Loaded: loaded (/lib/systemd/system/vault.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2021-11-16 21:55:13 UTC; 22s ago Docs: https://www.vaultproject.io/docs/ Main PID: 104207 (vault) Tasks: 7 (limit: 1137) Memory: 179.3M CGroup: /system.slice/vault.service └─104207 /usr/bin/vault server -config=/etc/vault.d/vault.hcl

      The output of that command should include several pieces of information about the running service, such as its process ID and resource usage. Ensure that the following line is included in the output, which indicates that the service is running correctly.

      Output

      . . . Active: active (running) . . .

      If the service is not active, take a look at the accompanying log lines at the end of the command’s output to see Vault’s output, which can help pinpoint any issues.

      Next, we’ll set an environment variable to tell the vault command how to connect to the Vault server. In Step 1 you configured Vault to only listen on the local loopback interface, so set the VAULT_ADDR environment variable to the local HTTPS endpoint.

      • export VAULT_ADDR=https://your_domain:8200

      The vault command can now communicate with the daemon. Note that defining the actual hostname instead of simply localhost or 127.0.0.1 is necessary to properly validate the HTTPS certificate.

      Confirm that the vault server is in an uninitialized state by checking its status.

      The server should return some output so that you can tell it is working but not yet initialized.

      Key Value
      --- -----
      Seal Type shamir
      Initialized false
      Sealed true
      Total Shares 0
      Threshold 0
      Unseal Progress 0/0
      Unseal Nonce n/a
      Version 1.8.5
      Storage Type file
      HA Enabled false
      

      There are two pieces of information that Vault will expose at initialization time that will not be available at any other point:

      • Initial root token. This is equivalent to root permissions to your Vault deployment, which allows the management of all Vault policies, mounts, and secrets.
      • Unseal keys. These are used to unseal Vault when the daemon starts, which permits the Vault daemon to decrypt the backend secret store.

      More specifically, Vault’s unsealing process decrypts the backend using a key formed by key shares. When you first initialize Vault, you may choose how many unseal keys to create and how many are necessary at unseal time to successfully unseal Vault. To learn more about Vault’s sealing mechanism, you can refer to the Vault documentation.

      A typical configuration for the unseal parameters would be to create three keys and require at least two of those keys at unseal time. This permits the important key shares to be separated and stored in distinct locations to ensure that compromising one is not sufficient to unseal Vault.

      In other words, whenever Vault is started, at least two unseal keys will be required in order to make the service become available and ready to use. While sealed, the files that store the actual secret values will remain encrypted and inaccessible.

      Initialize Vault with three unseal keys using the -key-shares=3 option, and require at least two keys to unseal the vault with the -key-threshold=2 flag::

      • vault operator init -key-shares=3 -key-threshold=2

      You will receive output like the following:

      Output

      Unseal Key 1: eZcJeydRrqeSMZ1zTN+VVll9TFT2KvJy7VlnxUgtvuz5 Unseal Key 2: ntmqCKq8rgNnKT1YSLCjVmCCZBAA3NwUeqxIyRpYD4Wm Unseal Key 3: 3FK1+Hsorh4p8/L9mki3VskaEU2eQhLqGOI/pJkTHMbx Initial Root Token: s.hY0ieybfDqCadz7JpL88uO3x

      Be sure to save each unseal token and the initial root token in a secure way. You will not be able to retrieve these keys and root token again. For example, one option would be to store one unseal key in a password manager, another on a USB drive, and another in a GPG-encrypted file.

      If you examine vault status again, the Initialized status will now be set to true, and the Total Shares and Threshold values will reflect the number of key shards and minimum number of keys that you will need to unseal the vault.

      Output

      . . . Initialized true Sealed true Total Shares 3 Threshold 2 Unseal Progress 0/2 . . .

      Note that the Unseal Progess line shows the value 0/2. Begin unsealing Vault using your newly created unseal tokens. Run the vault operator unseal command and input any of your keys when prompted:

      The command will ask for an unseal token:

      Output

      Key (will be hidden):

      After entering it, the output from the command will indicate that the unsealing is in progress, but still requires one more unsealing key before Vault is ready for use.

      Output

      Key Value --- ----- Seal Type shamir Initialized true Sealed true Total Shares 3 Threshold 2 Unseal Progress 1/2 Unseal Nonce 0f3a328b-e0c6-6294-d6a2-56da49271dff Version 1.8.5 Storage Type file HA Enabled false

      Notice how the Unseal Progress 1/2 line has changed in the output. Run the unseal command again.

      And enter a different key than the one you already used:

      Output

      Key (will be hidden):

      The command’s output indicates that the unseal process had completed successfully.

      Output

      Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 3 Threshold 2 Version 1.8.5 Storage Type file Cluster Name vault-cluster-3042c7bc Cluster ID c3e9d814-cf2a-2901-f0e4-ebc52d29e5cc HA Enabled false

      Vault is now unsealed and ready for use. These unseal steps are necessary whenever Vault is started or restarted.

      However, unsealing is a distinct process from normal interaction with Vault (such as reading and writing values), which are authenticated by tokens. In the next steps, we’ll create the necessary access tokens and policies to store secret values and read/write to specific paths in Vault.

      Step 4 — Reading and Writing Secrets

      There are several [secret backends]](https://www.vaultproject.io/docs/secrets/index.html) that you can use with Vault, but for this example we will use the kv secret backend. This backend stores simple key/value pairs in Vault. However, it is not enabled by default.

      In this section of the tutorial, you will enable the kv secret backend, and then learn how to read and write secrets to it.

      First, save the previously generated root token to a shell variable for ease of use.

      • root_token=your_root_token_here

      Next, while authenticating with the root token, enable the kv backend:

      • VAULT_TOKEN=$root_token vault secrets enable kv

      You will receive output like the following if the command is successful:

      Output

      Success! Enabled the kv secrets engine at: kv/

      You can then verify that it’s been added to your local list of available secrets backends:

      • VAULT_TOKEN=$root_token vault secrets list

      You should receive output like the following:

      Output

      Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_abc1631b per-token private secret storage identity/ identity identity_631fe262 identity store kv/ kv kv_4d5855c8 n/a sys/ system system_79b13f2f system endpoints used for control, policy and debugging

      Note the highlighted line that indicates the new kv backend is enabled. Now we can store some data with this backend.

      • VAULT_TOKEN=$root_token vault write kv/message value=mypassword

      In this command, the highlighted kv/ prefix indicates that we are writing to the kv backend mounted at the kv path, and we are storing the key value at the path message with the value mypassword. We used the root token, which has superuser privileges, to write the generic secret.

      Check the secret that you created using the vault read command:

      • VAULT_TOKEN=$root_token vault read kv/message

      You should receive output like the following, with the contents of the secret that you created:

      Output

      Key Value --- ----- refresh_interval 768h value mypassword

      However, creating, reading, and otherwise interacting with Vault using the Root Token only is not secure, scalable in a team setting, and does not allow for fine-grained access control to secrets. In the next section you’ll learn how to define policies and create additional access tokens to restrict how users can interact with Vault.

      Step 5 — Creating an Authorization Policy

      In a real-world scenario, you may store values like API keys or passwords that external tools can consume. Although you may read the secret value again using the root token, it is illustrative to generate a less privileged token with read-only permissions to our single secret.

      In this section of the tutorial you will create a Vault policy that will enforce read-only access to secrets. To create the policy you’ll need to edit a file and then load it into Vault using the vault policy command.

      To get started creating a policy, open a file called policy.hcl using nano or your preferred editor:

      Populate the file with the following Vault policy, which defines read-only access to the secret path::

      policy.hcl

      path "kv/message" {
           capabilities = ["read"]
      }
      

      Save and close the file, then write this policy to Vault. The following command will load the policy.hcl file into Vault and create a policy named message-readonly with the read-only capability

      • VAULT_TOKEN=$root_token vault policy write message-readonly policy.hcl

      Next, create a token that you will use for read-only access to Vault. Add the -policy=”message-readonly” flag to the vault token create command to use the new policy that you created:

      • VAULT_TOKEN=$root_token vault token create -policy="message-readonly"

      The output will look like this:

      Output

      Key Value --- ----- token your_token_value token_accessor your_token_accessor token_duration 768h0m0s token_renewable true token_policies ["default" "message-readonly"] identity_policies [] policies ["default" "message-readonly"]

      Save the highlighted your_token_value value to an environment variable called app_token:

      • app_token=your_token_value

      You can use the value of app_token to access the data stored in the path kv/message (and no other values in Vault).

      • VAULT_TOKEN=$app_token vault read kv/message

      Output

      Key Value --- ----- refresh_interval 768h0m0s value mypassword

      You can also test that this unprivileged token cannot perform other operations, such as listing secrets in Vault.

      • VAULT_TOKEN=$app_token vault list kv/

      Output

      Error reading kv/: Error making API request. URL: GET https://your_domain:8200/v1/secret?list=true Code: 403. Errors: * 1 error occurred: * permission denied

      This verifies that the less-privileged app token cannot perform any destructive actions or access other secret values aside from those explicitly stated in its Vault policy. If you would like to continue using the read-only token, be sure to record it somewhere safe for future use.

      Conclusion

      In this article you installed, configured, and deployed Vault on Ubuntu 20.04. You also created a sharded key to unseal Vault, enabled the kv backend secret store, and defined a read-only policy to limit how a user can interact with Vault secrets.

      Although this tutorial only demonstrated how to use an unprivileged token, the Vault documentation has more examples of additional ways to store and access secrets as well as alternative authentication methods.

      These instructions demonstrated how to deploy and use some of the core features of Vault. Your needs may require other configuration changes and more complex policies. Be sure to read the Vault documentation and make appropriate configuration changes for your needs. Some production-ready changes may include:

      • Generating lesser-privileged tokens for everyday use. The specific policies that these tokens should use depends on your specific use cases, but the example app_token in this tutorial illustrates how you can create limited-privilege tokens and policies.

      • If you are deploying Vault as part of a service that will be used by a team, initialize Vault with unseal keys for each team member. This approach can ensure that Vault’s storage is only decrypted when more than one team member participates in the process.



      Source link

      Erstellen eines Hashicorp Vault Server unter Verwendung von Packer und Terraform auf DigitalOcean


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Vault von Hashicorp ist ein Open Source Tool, um Zugangsdaten und sensible Daten in dynamischen Cloud-Umgebungen sicher zu speichern. Es bietet eine starke Datenverschlüsselung, identitätsbasierten Zugriff unter Verwendung von benutzerdefinierten Richtlinien, geheimes Leasen und Widerrufen sowie ein ausführliches Auditprotokoll, das fortlaufend aufgezeichnet wird. Vault bietet zudem eine HTTP-API und ist damit die ideale Wahl für die Speicherung von Anmeldeinformationen in verstreuten serviceorientierten Implementierungen wie Kubernetes.

      Packer und Terraform, ebenfalls von Hashicorp entwickelt, können zusammen verwendet werden, um Bilder von Vault zu kreieren und bereitzustellen. Innerhalb dieses Workflows können Entwickler Packer verwenden, um unveränderliche Bilder für verschiedene Plattformen aus einer einzelnen Konfigurationsdatei zu erstellen, die angibt, was das Bild enthalten soll. Terraform stellt dann so viele angepasste Exemplare der erstellten Bilder bereit, wie benötigt werden.

      In diesem Tutorial erstellen Sie mit Packer einen unveränderlichen Snapshot des Systems mit installiertem Vault und orchestrieren dessen Bereitstellung mit Terraform. Zum Schluss verfügen Sie über ein automatisiertes System zur Bereitstellung von Vault. So können Sie sich anstatt auf den zugrunde liegenden Installations- und Bereitstellungsprozess auf die Arbeit mit Vault selbst konzentrieren.

      Voraussetzungen

      • Auf Ihrem lokalen Rechner installierter Packer. Lesen Sie für Anweisungen die Offizielle Dokumentation.
      • Auf Ihrem lokalen Rechner installiertes Terraform. Lesen Sie die Offizielle Dokumentation für eine Anleitung.
      • Einen persönlichen Zugangs-Token (API-Schlüssel) mit Lese- und Schreibberechtigungen für Ihr DigitalOcean-Konto. Um einen solchen zu erstellen, besuchen Sie Erstellen eines persönlichen Zugangs-Tokens bei den Dokumenten.
      • Einen SSH-Schlüssel, den Sie zur Authentifizierung mit den bereitgestellten Vault Droplets verwenden, die auf Ihrem lokalen Rechner verfügbar sind und Ihrem DigitalOcean-Konto hinzugefügt werden. Sie benötigen auch dessen Fingerabdruck, den Sie von der Sicherheitsseite Ihres Kontos nach dem Erstellen kopieren können. Besuchen Sie die DigitalOcean Dokumentation für detaillierte Anweisungen oder das Tutorial Einrichten von SSH-Schlüsseln.

      Schritt 1 — Erstellen einer Packer-Vorlage

      In diesem Schritt schreiben Sie eine Packer-Konfigurationsdatei, die sogenannte Vorlage, die Packer anweist, wie ein Bild mit vorinstalliertem Vault erstellt werden kann. Sie schreiben die Konfiguration im Format JSON, einem gängigen, visuell lesbaren Dateiformat.

      Für die Zwecke dieses Tutorials speichern Sie alle Dateien unter ~/vault-orchestration. Erstellen Sie das Verzeichnis, indem Sie den folgenden Befehl ausführen:

      • mkdir ~/vault-orchestration

      Navigieren Sie dorthin:

      Sie speichern die Konfigurationsdateien für Packer und Terraform separat in verschiedenen Unterverzeichnissen. Erstellen Sie diese mit dem folgenden Befehl:

      Da Sie zuerst mit Packer arbeiten, navigieren Sie in dessen Verzeichnis:

      Verwenden von Vorlagenvariablen

      Die Speicherung von privaten Daten und Zugangsdaten für Applikationen in einer separaten Variablendatei ist der ideale Weg, diese aus Ihrer Vorlage herauszuhalten. Beim Erstellen des Bildes ersetzt Packer die angegebenen Variablen mit ihren Werten. Die Hartkodierung von geheimen Datenwerten in Ihre Vorlage ist ein Sicherheitsrisiko, insbesondere wenn sie mit Teammitgliedern geteilt oder auf öffentlichen Websites wie GitHub veröffentlicht werden soll.

      Sie speichern diese im Unterverzeichnis packer, in einer Datei namens variables.json​​​​​​. Erstellen Sie sie mit Ihrem bevorzugten Texteditor:

      Fügen Sie die folgenden Zeilen hinzu:

      ~/vault-orchestration/packer/variables.json

      {
          "do_token": "your_do_api_key",
          "base_system_image": "ubuntu-18-04-x64",
          "region": "nyc3",
          "size": "s-1vcpu-1gb"
      }
      

      Die Variablendatei besteht aus einem JSON-Wörterbuch, das die Variablennamen ihren Werten zuordnet. Sie verwenden diese Variablen in der Vorlage, die Sie erstellen. Wenn Sie möchten, können Sie die Werte Basisbild, Region und Droplet-Größe entsprechend den Entwicklerdokumenten bearbeiten.

      Denken Sie daran, your_do_api_key durch Ihren API-Schlüssel zu ersetzen, den Sie als Teil der Voraussetzungen erstellt haben. Speichern und schließen Sie dann die Datei.

      Erstellen von Buildern und Provisionern

      Mit der fertigen Variablendatei erstellen Sie nun die Packer-Vorlage selbst.

      Sie speichern die Packer-Vorlage für Vault in einer Datei namens template.json. Erstellen Sie sie mit Ihrem Texteditor:

      Fügen Sie die folgenden Zeilen hinzu:

      ~/vault-orchestration/packer/template.json

      {
           "builders": [{
               "type": "digitalocean",
               "api_token": "{{user `do_token`}}",
               "image": "{{user `base_system_image`}}",
               "region": "{{user `region`}}",
               "size": "{{user `size`}}",
               "ssh_username": "root"
           }],
           "provisioners": [{
               "type": "shell",
               "inline": [
                   "sleep 30",
                   "sudo apt-get update",
                   "sudo apt-get install unzip -y",
                   "curl -L https://releases.hashicorp.com/vault/1.3.2/vault_1.3.2_linux_amd64.zip -o vault.zip",
                   "unzip vault.zip",
                   "sudo chown root:root vault",
                   "mv vault /usr/local/bin/",
                   "rm -f vault.zip"
               ]
          }]
      }
      

      In der Vorlage definieren Sie Arrays von Buildern und Provisionern. Builder weisen Packer an, wie das Systembild (je nach Typ) zu erstellen ist und wo es gespeichert werden soll, während Provisioner eine Reihe von Aktionen enthalten, die Packer auf dem System durchführen muss, bevor es in ein unveränderliches Bild umgewandelt wird, wie z. B. die Installation oder Konfiguration von Software. Ohne Provisioner würden Sie zum Schluss ein unangetastetes Bild des Basissystems erhalten. Sowohl Builder als auch Provisioner stellen Parameter zur weiteren Anpassung des Workflows zur Verfügung.

      Sie definieren zuerst einen einzelnen Builder des Typs digitalocean, d. h. dass Packer beim Befehl zur Erstellung eines Bildes die bereitgestellten Parameter verwendet, um mit dem bereitgestellten API-Schlüssel ein temporäres Droplet der definierten Größe zu erstellen, mit dem angegebenen Basissystembild und der angegebenen Region. Das Format zum Abrufen einer Variablen ist {{user 'variable_name'}}, wobei der hervorgehobene Teil der Name ist.

      Wenn das provisorische Droplet bereitgestellt ist, stellt der Provisioner eine Verbindung über SSH mit dem angegebenen Benutzernamen her und führt nacheinander alle definierten Provisioner aus, bevor ein DigitalOcean Snapshot aus dem Droplet erstellt und es gelöscht wird.

      Es handelt sich um eine Shell, die die angegebenen Befehle auf dem Ziel ausführt. Die Befehle können entweder inline als Array von Zeichenfolgen angegeben oder in getrennten Skriptdateien definiert werden, wenn das Einfügen in die Vorlage aufgrund der Größe zu umständlich wird. Die Befehle in der Vorlage warten 30 Sekunden, bis das System hochgefahren ist. Anschließend wird Vault 1.3.2 heruntergeladen und entpackt. Konsultieren Sie die Offizielle Vault Downloadseite und ersetzen Sie den Link in den Befehlen durch eine neuere Version für Linux, wenn verfügbar.

      Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Um die Gültigkeit Ihrer Vorlage zu überprüfen, führen Sie den folgenden Befehl aus:

      • packer validate -var-file=variables.json template.json

      Packer akzeptiert einen Pfad zur Variablendatei über das Argument -var-file.

      Sie sehen die folgende Ausgabe:

      Output

      Template validated successfully.

      Sollten Sie eine Fehlermeldung erhalten, gibt Packer genau an, wo dieser aufgetreten ist, sodass Sie diesen korrigieren können.

      Nun haben Sie eine funktionierende Vorlage, die ein Bild mit installiertem Vault erzeugt, wobei Ihr API-Schlüssel und andere Parameter in einer separaten Datei definiert sind. Jetzt können Sie Packer aufrufen und den Snapshot erstellen.

      Schritt 2 — Erstellen des Snapshot

      In diesem Schritt erstellen Sie einen DigitalOcean Snapshot aus Ihrer Vorlage mit dem Packerbefehl build.

      Um Ihren Snapshot zu erstellen, führen Sie den folgenden Befehl aus:

      • packer build -var-file=variables.json template.json

      Die Ausführung des Befehls nimmt etwas Zeit in Anspruch. Sie sehen eine Menge Ausgabe, die so aussehen wird:

      Output

      digitalocean: output will be in this color. ==> digitalocean: Creating temporary ssh key for droplet... ==> digitalocean: Creating droplet... ==> digitalocean: Waiting for droplet to become active... ==> digitalocean: Using ssh communicator to connect: ... ==> digitalocean: Waiting for SSH to become available... ==> digitalocean: Connected to SSH! ==> digitalocean: Provisioning with shell script: /tmp/packer-shell035430322 ... ==> digitalocean: % Total % Received % Xferd Average Speed Time Time Time Current ==> digitalocean: Dload Upload Total Spent Left Speed digitalocean: Archive: vault.zip ==> digitalocean: 100 45.5M 100 45.5M 0 0 154M 0 --:--:-- --:--:-- --:--:-- 153M digitalocean: inflating: vault ==> digitalocean: Gracefully shutting down droplet... ==> digitalocean: Creating snapshot: packer-1581537927 ==> digitalocean: Waiting for snapshot to complete... ==> digitalocean: Destroying droplet... ==> digitalocean: Deleting temporary ssh key... Build 'digitalocean' finished. ==> Builds finished. The artifacts of successful builds are: --> digitalocean: A snapshot was created: 'packer-1581537927' (ID: 58230938) in regions '...'

      Packer protokolliert alle Schritte, die es beim Erstellen Ihrer Vorlage vorgenommen hat. Die letzte Zeile enthält den Namen des Snapshots (wie packer-1581537927) und seine rot markierte ID in Klammern. Notieren Sie die ID Ihres Snapshots, da Sie diese im nächsten Schritt benötigen.

      Falls der Build-Prozess durch Fehler in der API fehlschlägt, warten Sie einige Minuten und versuchen Sie es dann erneut.

      Sie haben nun einen DigitalOcean Snapshot entsprechend Ihrer Vorlage erstellt. Auf dem Snapshot ist Vault vorinstalliert und Sie können nun Droplets mit ihm als Systembild bereitstellen. Im nächsten Schritt schreiben Sie die Terraform-Konfiguration zur Automatisierung solcher Bereitstellungen.

      Schritt 3 — Schreiben der Terraform-Konfiguration

      In diesem Schritt schreiben Sie die Terraform-Konfiguration zur Automatisierung der Droplet-Bereitstellungen des Snapshots, der den gerade mit Packer erstellten Vault enthält.

      Bevor Sie die eigentliche Terraform-Konfiguration zur Bereitstellung von Vault aus dem zuvor erstellten Snapshot schreiben, müssen Sie hierzu zunächst den DigitalOcean-Provider konfigurieren. Navigieren Sie zum Terraform-Unterverzeichnis, indem Sie Folgendes ausführen:

      • cd ~/vault-orchestration/terraform

      Erstellen Sie dann eine Datei namens do-provider.tf, in der Sie den Provider speichern:

      Fügen Sie die folgenden Zeilen hinzu:

      ~/vault-orchestration/terraform/do-provider.tf

      variable "do_token" {
      }
      
      variable "ssh_fingerprint" {
      }
      
      variable "instance_count" {
        default = "1"
      }
      
      variable "do_snapshot_id" {
      }
      
      variable "do_name" {
        default = "vault"
      }
      
      variable "do_region" {
      }
      
      variable "do_size" {
      }
      
      variable "do_private_networking" {
        default = true
      }
      
      provider "digitalocean" {
        token = var.do_token
      }
      

      Diese Datei gibt Parametervariablen an und verleiht dem digitalocean-Provider einen API-Schlüssel. Sie verwenden diese Variablen später in Ihrer Terraform-Vorlage, aber Sie müssen zuerst deren Werte festlegen. Zu diesem Zweck unterstützt Terraform die Angabe der variablen Werte in einer Variablendefinitionsdatei, ähnlich wie bei Packer. Der Dateiname muss entweder in .tfvars oder .tfvars.json enden. Sie übergeben diese Datei später an Terraform mit dem Argument -var-file.

      Speichern und schließen Sie die Datei.

      Erstellen Sie eine Variablendefinitionsdatei mit dem Namen definitions.tfvars mithilfe Ihres Texteditors:

      Fügen Sie die folgenden Zeilen hinzu:

      ~/vault-orchestration/terraform/definitions.tf

      do_token         = "your_do_api_key"
      ssh_fingerprint  = "your_ssh_key_fingerprint"
      do_snapshot_id   = your_do_snapshot_id
      do_name          = "vault"
      do_region        = "nyc3"
      do_size          = "s-1vcpu-1gb"
      instance_count   = 1
      

      Ersetzen Sie your_do_api_key, your_ssh_key_fingerprint und your_do_snapshot_id jeweils mit dem API-Schlüssel Ihres Kontos, dem Fingerabdruck Ihres SSH-Schlüssels und der aus dem vorherigen Schritt erhaltenen Snapshot-ID. Die Parameter do_region und do_size müssen die gleichen Werte wie in der Packer-Variablendatei haben. Wenn Sie mehrere Exemplare gleichzeitig bereitstellen möchten, stellen Sie instance_count auf den gewünschten Wert.

      Danach speichern und schließen Sie die Datei.

      Weitere Informationen über den DigitalOcean Terraform Provider finden Sie in den Offiziellen Dokumenten.

      Sie speichern die Vault Snapshot-Bereitstellungskonfiguration in einer Datei namens deployment.tf, unter dem Verzeichnis terraform. Erstellen Sie sie mit Ihrem Texteditor:

      Fügen Sie die folgenden Zeilen hinzu:

      ~/vault-orchestration/terraform/deployment.tf

      resource "digitalocean_droplet" "vault" {
        count              = var.instance_count
        image              = var.do_snapshot_id
        name               = var.do_name
        region             = var.do_region
        size               = var.do_size
        private_networking = var.do_private_networking
        ssh_keys = [
          var.ssh_fingerprint
        ]
      }
      
      output "instance_ip_addr" {
        value = {
          for instance in digitalocean_droplet.vault:
          instance.id => instance.ipv4_address
        }
        description = "The IP addresses of the deployed instances, paired with their IDs."
      }
      

      Hier definieren Sie eine einzelne Ressource des Typs digitalocean_droplet namens vault. Danach legen Sie seine Parameter entsprechend den Variablenwerten fest und fügen einen SSH-Schlüssel (mit seinem Fingerabdruck) von Ihrem DigitalOcean-Konto zur Droplet-Ressource hinzu. Zum Schluss erfolgt das output der IP-Adressen aller neu erstellten Exemplare an die Konsole.

      Speichern und schließen Sie die Datei.

      Bevor Sie die Bereitstellungskonfiguration einsetzen, müssen Sie das Verzeichnis als Terraform-Projekt initialisieren:

      Sie sehen die folgende Ausgabe:

      Output

      Initializing the backend... Initializing provider plugins... The following providers do not have any version constraints in configuration, so the latest version was installed. To prevent automatic upgrades to new major versions that may contain breaking changes, it is recommended to add version = "..." constraints to the corresponding provider blocks in configuration, with the constraint strings suggested below. * provider.digitalocean: version = "~> 1.14" Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

      Bei der Initialisierung eines Verzeichnisses als Projekt liest Terraform die verfügbaren Konfigurationsdateien ein und lädt die als notwendig erachteten Plugins herunter, wie in der Ausgabe protokolliert.

      Sie verfügen jetzt über die Terraform-Konfiguration, um Ihren Vault Snapshot bereitzustellen. Sie können diese nun validieren und in einem Droplet bereitstellen.

      Schritt 4 — Bereitstellen von Vault mit Terraform

      In diesem Abschnitt verifizieren Sie die Terraform-Konfiguration mit dem Befehl validate. Nach erfolgreicher Verifizierung wenden Sie sie mit apply an und stellen als Ergebnis ein Droplet bereit.

      Führen Sie den folgenden Befehl aus, um die Gültigkeit Ihrer Konfiguration zu testen:

      Sie sehen die folgende Ausgabe:

      Output

      Success! The configuration is valid.

      Führen Sie als Nächstes den Befehl plan aus, um zu sehen, wie Terraform sich verhält, um die Infrastruktur entsprechend Ihrer Konfiguration bereitzustellen:

      • terraform plan -var-file="definitions.tfvars"

      Terraform akzeptiert eine Variablendefinitionsdatei mit dem Parameter -var-file.

      Die Ausgabe wird ähnlich sein wie diese:

      Output

      Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.vault[0] will be created + resource "digitalocean_droplet" "vault" { ... } Plan: 1 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.

      Das grüne + am Anfang der Zeile resource "digitalocean_droplet" "vault" bedeutet, dass Terraform ein neues Droplet mit dem Namen vault erstellt, wobei es folgende Parameter verwendet. Das ist korrekt und nun können Sie den Plan mit terraform apply ausführen:

      • terraform apply -var-file="definitions.tfvars"

      Geben Sie bei Nachfrage yes ein. Nach einigen Minuten ist die Bereitstellung durch das Droplet abgeschlossen und Sie sehen eine Ausgabe ähnlich wie diese:

      Output

      An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: + digitalocean_droplet.vault-droplet ... Plan: 1 to add, 0 to change, 0 to destroy. ... digitalocean_droplet.vault-droplet: Creating... ... Apply complete! Resources: 1 added, 0 changed, 0 destroyed. Outputs: instance_ip_addr = { "181254240" = "your_new_server_ip" }

      In der Ausgabe protokolliert Terraform die ausgeführten Aktionen (in diesem Fall zur Erstellung eines Droplets) und zeigt am Ende seine öffentliche IP-Adresse an. Diese nutzen Sie, um sich im nächsten Schritt mit Ihrem neuen Droplet zu verbinden.

      Sie haben ein neues Droplet aus dem Snapshot mit Vault erstellt und können es nun verifizieren.

      Schritt 5 — Verifizieren Ihres bereitgestellten Droplets

      In diesem Schritt greifen Sie mit SSH auf Ihr neues Droplet zu und verifizieren, dass Vault korrekt installiert wurde.

      Wenn Sie mit Windows arbeiten, können Sie Software wie Kitty oder Putty verwenden, um sich mit dem Droplet über einen SSH-Schlüssel zu verbinden.

      Auf Linux- und macOS-Rechnern können Sie den bereits verfügbaren Befehl ssh verwenden, um eine Verbindung herzustellen:

      Geben Sie bei Nachfrage yes ein. Nach der Anmeldung starten Sie Vault, indem Sie Folgendes ausführen:

      Sie sehen seine “Hilfe”-Ausgabe, die folgendermaßen aussieht:

      Output

      Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

      Sie können die Verbindung durch Eingabe von exit beenden.

      Sie haben nun verifiziert, dass Ihr neu bereitgestelltes Droplet aus dem von Ihnen erstellten Snapshot kreiert wurde, und dass Vault korrekt installiert ist.

      Zusammenfassung

      Sie verfügen jetzt über ein automatisiertes System zur Bereitstellung von Hashicorp Vault auf DigitalOcean Droplets mit Unterstützung von Terraform und Packer. Sie können nun so viele Vault-Server bereitstellen, wie Sie benötigen. Um Vault zu verwenden, müssen Sie es initialisieren und weiter konfigurieren. Anweisungen hierzu finden Sie in den Offiziellen Dokumenten.

      Weitere Tutorials zur Verwendung von Terraform finden Sie auf der Terraform Content Page.



      Source link

      Comment construire un serveur Hashicorp Vault en utilisant Packer et Terraform sur DigitalOcean


      L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’une donation dans le cadre du programme Write for Donations.

      Introduction

      Vault, de Hashicorp, est un outil open-source permettant de stocker en toute sécurité des secrets et des données sensibles dans des environnements cloud dynamiques. Il offre un cryptage solide des données, un accès basé sur l’identité à l’aide de politiques personnalisées, ainsi qu’une location et une révocation secrètes, de même qu’un journal d’audit détaillé, enregistré à tout moment. Vault dispose également d’une API HTTP, ce qui en fait le choix idéal pour le stockage d’identifiants dans des déploiements dispersés orientés sur les services tels que Kubernetes.

      Packer et Terraform, également développés par Hashicorp, peuvent être utilisés ensemble pour créer et déployer des images de Vault. Dans le cadre de ce flux de travail, les développeurs peuvent utiliser Packer pour écrire des images immuables pour différentes plateformes à partir d’un seul fichier de configuration qui spécifie ce que l’image doit contenir. Terraform déploiera ensuite le nombre requis d’instances personnalisées des images créées.

      Dans ce tutoriel, vous utiliserez Packer pour créer un instantané immuable du système avec Vault installé, et orchestrer son déploiement à l’aide de Terraform. Au final, vous disposerez d’un système automatisé pour le déploiement de Vault, ce qui vous permettra de vous concentrer sur le travail avec Vault lui-même et non sur le processus d’installation et d’approvisionnement sous-jacent.

      Conditions préalables

      • Packer installé sur votre machine locale. Pour obtenir des instructions, consultez la documentation officielle.
      • Terraform installé sur votre machine locale. Consultez la documentation officielle pour obtenir un guide.
      • Un jeton d’accès personnel (clé API) avec des droits en lecture et en écriture pour votre compte DigitalOcean. Pour savoir comment en créer un, consultez le tutoriel Comment créer un jeton d’accès personnel de la documentation.
      • Une clé SSH que vous utiliserez pour vous authentifier avec les droplets Vault déployées ; elle est disponible sur votre machine locale et ajoutée à votre compte DigitalOcean. Vous aurez également besoin de l’empreinte digitale associée, que vous pourrez copier à partir de la page de sécurité de votre compte une fois que vous l’aurez ajoutée. Consultez la documentation de DigitalOcean pour obtenir des instructions détaillées, ou encore le tutoriel Comment configurer les clés SSH.

      Étape 1 – Création d’un modèle Packer

      Dans cette étape, vous allez écrire un fichier de configuration Packer, appelé modèle, qui indiquera à Packer comment construire une image contenant Vault préinstallé. Vous allez écrire la configuration au format JSON, un format de fichier de configuration couramment utilisé, lisible par l’homme.

      Aux fins de ce tutoriel, vous allez stocker tous les fichiers sous ~/vault-orchestration. Créez le répertoire en exécutant la commande suivante :

      • mkdir ~/vault-orchestration

      Rendez-vous-y :

      Vous stockerez les fichiers de configuration pour Packer et Terraform séparément, dans des sous-répertoires différents. Créez-les en utilisant la commande suivante :

      Comme vous allez d’abord travailler avec Packer, naviguez vers son répertoire :

      Utilisation des variables du modèle

      Le stockage de données privées et de secrets d’application dans un fichier de variables séparé est le moyen idéal de les tenir à l’écart de votre modèle. Lors de la construction de l’image, Packer remplacera les variables référencées par leurs valeurs. Le codage en dur de valeurs secrètes dans votre modèle constitue un risque pour la sécurité, surtout s’il doit être communiqué aux membres de l’équipe ou affiché sur des sites publics tels que GitHub.

      Vous les stockerez dans le sous-répertoire packer, dans un fichier appelé variables.json. Créez celui-ci avec votre éditeur de texte préféré :

      Ajoutez les lignes suivantes :

      ~/vault-orchestration/packer/variables.json

      {
          "do_token": "your_do_api_key",
          "base_system_image": "ubuntu-18-04-x64",
          "region": "nyc3",
          "size": "s-1vcpu-1gb"
      }
      

      Le fichier de variables se compose d’un dictionnaire JSON, qui associe les noms de variables à leurs valeurs. Vous utiliserez ces variables dans le modèle que vous êtes sur le point de créer. Si vous le souhaitez, vous pouvez modifier les valeurs de l’image de base, de la région et de la taille des droplets, en fonction de la documentation des développeurs.

      N’oubliez pas de remplacer your_do_api_key par votre clé API que vous avez créée dans le cadre des conditions préalables, puis enregistrez et fermez le fichier.

      Créer des constructeurs et des fournisseurs

      Le fichier de variables étant prêt, vous allez maintenant créer le modèle Packer lui-même.

      Vous allez stocker le modèle Packer pour Vault dans un fichier nommé template.json. Créez celui-ci avec votre éditeur de texte :

      Ajoutez les lignes suivantes :

      ~/vault-orchestration/packer/template.json

      {
           "builders": [{
               "type": "digitalocean",
               "api_token": "{{user `do_token`}}",
               "image": "{{user `base_system_image`}}",
               "region": "{{user `region`}}",
               "size": "{{user `size`}}",
               "ssh_username": "root"
           }],
           "provisioners": [{
               "type": "shell",
               "inline": [
                   "sleep 30",
                   "sudo apt-get update",
                   "sudo apt-get install unzip -y",
                   "curl -L https://releases.hashicorp.com/vault/1.3.2/vault_1.3.2_linux_amd64.zip -o vault.zip",
                   "unzip vault.zip",
                   "sudo chown root:root vault",
                   "mv vault /usr/local/bin/",
                   "rm -f vault.zip"
               ]
          }]
      }
      

      Dans le modèle, vous définissez des tableaux de constructeurs et de fournisseurs. Les constructeurs indiquent à Packer comment construire l’image du système (en fonction de leur type) et où la stocker, tandis que les fournisseurs contiennent des ensembles d’actions que Packer doit effectuer sur le système avant de le transformer en une image immuable, comme l’installation ou la configuration de logiciels. Sans fournisseurs, vous vous retrouveriez avec une image du système de base inchangée. Les constructeurs et les fournisseurs exposent des paramètres pour une personnalisation plus poussée du flux de travail.

      Vous définissez d’abord un constructeur unique du type digitalocean, ce qui signifie que lorsqu’on lui commande de construire une image, Packer utilisera les paramètres fournis pour créer une droplet temporaire de la taille définie en utilisant la clé API fournie avec l’image du système de base spécifiée et dans la région spécifiée. Le format permettant de récupérer une variable est {{user 'variable_name'}}, où la partie surlignée représente son nom.

      Lorsque la droplet temporaire est fournie, le fournisseur se connectera à celle-ci en utilisant SSH avec le nom d’utilisateur spécifié, et exécutera séquentiellement tous les fournisseurs définis, avant de créer un instantané DigitalOcean à partir de la droplet et de le supprimer.

      Il est de type shell, qui va exécuter les commandes données sur la cible. Les commandes peuvent être spécifiées soit en ligne (sous la forme d’un tableau de chaînes de caractères), soit définies dans des fichiers de script séparés si leur insertion dans le modèle devient difficile en raison de leur taille. Les commandes du modèle attendront 30 secondes pour que le système démarre, puis téléchargeront et décompresseront Vault 1.3.2. Consultez la page officielle de téléchargement de Vault et remplacez le lien présent dans les commandes par une version plus récente pour Linux, si disponible.

      Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Pour vérifier la validité de votre modèle, exécutez la commande suivante :

      • packer validate -var-file=variables.json template.json

      Packer accepte un chemin vers le fichier de variables via l’argument -var-file.

      Vous verrez la sortie suivante :

      Output

      Template validated successfully.

      Si vous obtenez une erreur, Packer vous indiquera exactement où elle s’est produite afin que vous puissiez la corriger.

      Vous disposez maintenant d’un modèle de travail qui produit une image avec Vault installé, avec votre clé API et d’autres paramètres définis dans un fichier séparé. Vous êtes prêt à appeler Packer et à construire l’instantané.

      Étape 2 – Création de l’instantané

      Dans cette étape, vous allez construire un instantané DigitalOcean à partir de votre modèle en utilisant la commande Packer build.

      Pour créer votre instantané, exécutez la commande suivante :

      • packer build -var-file=variables.json template.json

      L’exécution de cette commande prendra un certain temps. Vous verrez beaucoup de sorties qui ressembleront à ceci :

      Output

      digitalocean: output will be in this color. ==> digitalocean: Creating temporary ssh key for droplet... ==> digitalocean: Creating droplet... ==> digitalocean: Waiting for droplet to become active... ==> digitalocean: Using ssh communicator to connect: ... ==> digitalocean: Waiting for SSH to become available... ==> digitalocean: Connected to SSH! ==> digitalocean: Provisioning with shell script: /tmp/packer-shell035430322 ... ==> digitalocean: % Total % Received % Xferd Average Speed Time Time Time Current ==> digitalocean: Dload Upload Total Spent Left Speed digitalocean: Archive: vault.zip ==> digitalocean: 100 45.5M 100 45.5M 0 0 154M 0 --:--:-- --:--:-- --:--:-- 153M digitalocean: inflating: vault ==> digitalocean: Gracefully shutting down droplet... ==> digitalocean: Creating snapshot: packer-1581537927 ==> digitalocean: Waiting for snapshot to complete... ==> digitalocean: Destroying droplet... ==> digitalocean: Deleting temporary ssh key... Build 'digitalocean' finished. ==> Builds finished. The artifacts of successful builds are: --> digitalocean: A snapshot was created: 'packer-1581537927' (ID: 58230938) in regions '...'

      Packer enregistre toutes les étapes de la création de votre modèle. La dernière ligne contient le nom de l’instantané (tel que packer-1581537927) et son identifiant entre parenthèses, marqué en rouge. Notez votre ID de l’instantané, car vous en aurez besoin à l’étape suivante.

      Si le processus de construction échoue à cause d’erreurs d’API, attendez quelques minutes puis réessayez.

      Vous avez construit un instantané DigitalOcean selon votre modèle. L’instantané contient Vault préinstallé, et vous pouvez maintenant déployer les droplets avec lui comme image système. Dans l’étape suivante, vous allez écrire la configuration de Terraform pour automatiser ces déploiements.

      Étape 3 – Rédaction de la configuration de Terraform

      Dans cette étape, vous allez écrire la configuration de Terraform pour automatiser les déploiements de droplets de l’instantané contenant Vault que vous venez de construire avec Packer.

      Avant d’écrire la configuration réelle de Terraform pour le déploiement de Vault à partir de l’instantané construit précédemment, vous devrez d’abord configurer le fournisseur DigitalOcean pour celui-ci. Naviguez vers le sous-répertoire terraform en exécutant :

      • cd ~/vault-orchestration/terraform

      Ensuite, créez un fichier nommé do-provider.tf, où vous stockerez le fournisseur :

      Ajoutez les lignes suivantes :

      ~/vault-orchestration/terraform/do-provider.tf

      variable "do_token" {
      }
      
      variable "ssh_fingerprint" {
      }
      
      variable "instance_count" {
        default = "1"
      }
      
      variable "do_snapshot_id" {
      }
      
      variable "do_name" {
        default = "vault"
      }
      
      variable "do_region" {
      }
      
      variable "do_size" {
      }
      
      variable "do_private_networking" {
        default = true
      }
      
      provider "digitalocean" {
        token = var.do_token
      }
      

      Ce fichier déclare les variables de paramètres et fournit au fournisseur digitalocean une clé API. Vous utiliserez plus tard ces variables dans votre modèle Terraform, mais vous devrez d’abord spécifier leurs valeurs. Pour cela, Terraform permet de spécifier des valeurs de variables dans un fichier de définitions de variables, de façon similaire à Packer. Le nom de fichier doit se terminer par .tfvars ou .tfvars.json. Vous transmettrez plus tard ce fichier à Terraform en utilisant l’argument -var-file.

      Enregistrez et fermez le fichier.

      Créez un fichier de définitions de variables appelé definitions.tfvars en utilisant votre éditeur de texte : 

      Ajoutez les lignes suivantes :

      ~/vault-orchestration/terraform/definitions.tf

      do_token         = "your_do_api_key"
      ssh_fingerprint  = "your_ssh_key_fingerprint"
      do_snapshot_id   = your_do_snapshot_id
      do_name          = "vault"
      do_region        = "nyc3"
      do_size          = "s-1vcpu-1gb"
      instance_count   = 1
      

      N’oubliez pas de remplacer your_do_api_key, your_ssh_key_fingerprint, et your_do_snapshot_id par la clé API de votre compte, l’empreinte digitale de votre clé SSH, et l’identifiant de l’instantané que vous avez noté à l’étape précédente, respectivement. Les paramètres do_region et do_size doivent porter les mêmes valeurs que dans le fichier de variables Packer. Si vous souhaitez déployer plusieurs instances en même temps, ajustez instance_count à la valeur souhaitée. 

      Lorsque vous avez terminé, sauvegardez et fermez le fichier.

      Pour plus d’informations sur le fournisseur DigitalOcean Terraform, consultez les documents officiels. 

      Vous allez stocker la configuration de déploiement de l’instantané de Vault dans un fichier nommé deployment.tf, sous le répertoire terraform. Créez celui-ci avec votre éditeur de texte :

      Ajoutez les lignes suivantes :

      ~/vault-orchestration/terraform/deployment.tf

      resource "digitalocean_droplet" "vault" {
        count              = var.instance_count
        image              = var.do_snapshot_id
        name               = var.do_name
        region             = var.do_region
        size               = var.do_size
        private_networking = var.do_private_networking
        ssh_keys = [
          var.ssh_fingerprint
        ]
      }
      
      output "instance_ip_addr" {
        value = {
          for instance in digitalocean_droplet.vault:
          instance.id => instance.ipv4_address
        }
        description = "The IP addresses of the deployed instances, paired with their IDs."
      }
      

      Vous définissez ici une ressource unique du type digitalocean_droplet nommée vault. Ensuite, vous définissez ses paramètres en fonction des valeurs des variables et ajoutez une clé SSH (en utilisant son empreinte digitale) de votre compte DigitalOcean à la ressource droplet. Enfin, vous output à la console les adresses IP de toutes les instances qui viennent d’être déployées.

      Enregistrez et fermez le fichier.

      Avant de faire quoi que ce soit d’autre avec votre configuration de déploiement, vous devrez initialiser le répertoire en tant que projet Terraform :

      Vous verrez la sortie suivante :

      Output

      Initializing the backend... Initializing provider plugins... The following providers do not have any version constraints in configuration, so the latest version was installed. To prevent automatic upgrades to new major versions that may contain breaking changes, it is recommended to add version = "..." constraints to the corresponding provider blocks in configuration, with the constraint strings suggested below. * provider.digitalocean: version = "~> 1.14" Terraform has been successfully initialized! You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work. If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

      Lors de l’initialisation d’un répertoire en tant que projet, Terraform lit les fichiers de configuration disponibles et télécharge les plugins jugés nécessaires, tels qu’ils sont enregistrés dans la sortie.

      Vous disposez maintenant de la configuration de Terraform à utiliser pour le déploiement de votre instantané Vault. Vous pouvez passer à la validation et au déploiement sur une Droplet.

      Étape 4 – Déploiement de Vault à l’aide de Terraform

      Dans cette section, vous allez vérifier votre configuration Terraform à l’aide de la commande validate. Une fois qu’elle aura été vérifiée avec succès, vous l'appliquerez et déploierez une droplet en conséquence.

      Exécutez la commande suivante pour tester la validité de votre configuration :

      Vous verrez la sortie suivante :

      Output

      Success! The configuration is valid.

      Ensuite, lancez la commande plan pour voir ce que Terraform va tenter pour fournir l’infrastructure en fonction de votre configuration :

      • terraform plan -var-file="definitions.tfvars"

      Terraform accepte un fichier de définitions de variables via le paramètre -var-file.

      Le résultat sera similaire à :

      Output

      Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # digitalocean_droplet.vault[0] will be created + resource "digitalocean_droplet" "vault" { ... } Plan: 1 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.

      Le + vert au début de la ligne de la ressource "digitalocean_droplet" "vault" signifie que Terraform va créer une nouvelle droplet appelée vault en utilisant les paramètres qui suivent. Ceci est correct, vous pouvez donc maintenant exécuter le plan en lançant l’application terraform :

      • terraform apply -var-file="definitions.tfvars"

      Entrez yes (oui) lorsque cela vous est demandé. Après quelques minutes, la droplet terminera l’approvisionnement et vous verrez un résultat similaire à celui-ci :

      Output

      An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: + digitalocean_droplet.vault-droplet ... Plan: 1 to add, 0 to change, 0 to destroy. ... digitalocean_droplet.vault-droplet: Creating... ... Apply complete! Resources: 1 added, 0 changed, 0 destroyed. Outputs: instance_ip_addr = { "181254240" = "your_new_server_ip" }

      Dans la sortie, Terraform enregistre les actions qu’il a effectuées (dans ce cas, pour créer une droplet) et affiche son adresse IP publique à la fin. Vous l’utiliserez pour vous connecter à votre nouvelle droplet, lors de la prochaine étape.

      Vous avez créé une nouvelle droplet à partir de l’instantané contenant Vault et vous êtes maintenant prêt à la vérifier.

      Étape 5 – Vérification de votre droplet déployée

      Dans cette étape, vous allez accéder à votre nouvelle droplet en utilisant SSH et vérifier que Vault a été installé correctement.

      Si vous êtes sous Windows, vous pouvez utiliser un logiciel tel que Kitty ou Putty pour vous connecter à la droplet à l’aide d’une clé SSH.

      Sur les machines Linux et macOS, vous pouvez utiliser la commande ssh déjà disponible pour vous connecter :

      Répondez yes (oui) lorsque cela vous est demandé. Une fois que vous êtes connecté, lancez Vault en exécutant :

      Vous verrez sa sortie « aide », qui ressemble à ceci :

      Output

      Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

      Vous pouvez quitter la connexion en tapant exit.

      Vous avez maintenant vérifié que votre droplet qui vient d’être déployée a été créée à partir de l’instantané que vous avez créé, et que Vault est correctement installé.

      Conclusion

      Vous disposez maintenant d’un système automatisé pour déployer Vault de Hashicorp sur les droplets DigitalOcean en utilisant Terraform et Packer. Vous pouvez désormais déployer autant de serveurs Vault que nécessaire. Pour commencer à utiliser Vault, vous devez l’initialiser et le configurer davantage. Pour savoir comment procéder, consultez les documents officiels.

      Pour accéder à d’autres tutoriels sur l’utilisation de Terraform, consultez notre page de contenus Terraform.



      Source link