GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free: gitlabcommitvirtual2021.com

Commit 1aaddd0d authored by Lorenzo Setale's avatar Lorenzo Setale
Browse files

Fixes typos

parent bd200240
......@@ -11,3 +11,4 @@ packer/credentials.json
.terraform
*.tfstate*
*.tfvars
.vscode
\ No newline at end of file
......@@ -37,7 +37,7 @@ panic: rotate seal
token_pipeline:
# Create a pipeline token capable of reading atlas secrets, that has 1w as life
# time and can be renewed for a max of 4 weeks. It is orphan so that when
# revokign the root token this will not be revoked too.
# revoking the root token this will not be revoked too.
#
vault token create \
-orphan -display-name="pipeline" \
......
......@@ -3,16 +3,16 @@ Hey surfer! This repository has been updated on 2020/03/21, so some
sections might be outdated if you are reading this from the future! 😉
This repository contains [Hashicorp Vault](https://vaultproject.io)
configuration and immutable infrastucture setup.
configuration and immutable infrastructure setup.
It is automated via Terraform and [GitLab](https://gitlab.com/qm64/vault)
pipeline but it requires an initial setup that is manual. It uses some immutable
infrastucture concept to deploy a AWS EC2 instance on Hashicorp Vault
infrastructure concept to deploy a AWS EC2 instance on Hashicorp Vault
without manual operations. It can be easily modified to use other cloud vendors
as the setup is cloud agnostic.
**Important Note**: most of this repository's is an example used in
this blog post: [Exploring Immutalbe Infrastructure on Vault](https://qm64.tech/posts/202003-immutable-infrastructure-vault/) for [Qm64](https://qm64.tech).
this blog post: [Exploring Immutable Infrastructure on Vault](https://qm64.tech/posts/202003-immutable-infrastructure-vault/) for [Qm64](https://qm64.tech).
this should be considered as an example and it requires changes in order to
be used! **READ THE README FILES** and please check the original
[GitLab repository](https://gitlab.com/qm64/vault) for the latest updates.
......@@ -22,8 +22,8 @@ be used! **READ THE README FILES** and please check the original
credentials are set correctly. _Why?_
Because if there is no Vault deployed yet, we need a manual way to deploy it!
After that Gitlab CI/CD pipeline is capable to obtain temporary credentials from
Vautl itself. To acheive this we are using Make. Check the `Makefile`s to know
After that GitLab CI/CD pipeline is capable to obtain temporary credentials from
Vault itself. To achieve this we are using Make. Check the `Makefile`s to know
more. 😅
For the first deploy please make sure that your environment has the following
......@@ -90,7 +90,7 @@ under `./infrastructure`
Please read more in [the related README file](./configuration/README.md)
This is not part of the immutable infrastructure but about configuring Vault.
After vault has been deployed it [needs to be initalized](https://learn.hashicorp.com/vault/getting-started/deploy#initializing-the-vault).
After vault has been deployed it [needs to be initialized](https://learn.hashicorp.com/vault/getting-started/deploy#initializing-the-vault).
This is a manual operation: Set up `VAULT_ADDR` env variable to your domain and run:
```shell
......@@ -140,7 +140,7 @@ First we initiate the process:
make recover_root
```
Then we ask the people holding the vault unsealink keys to run
Then we ask the people holding the vault unsealing keys to run
`vault operator generate-root` and to follow the instructions on screen.
This is not required if we are using a cloud provided KMS solution.
......
# Cereate a S3 bucket that will be used by vault.
# Create a S3 bucket that will be used by vault.
# Note that the name is random so that we can test it on multiple environments
# for multiple versions. Note also the prevent destroy to reduce the risk of
# data loss in case we accidentally run `terraform destroy` ;-)
......
# This security group is exposing HTTPS to Cloudflare.
# This is just an example, and is relying on Cloudflare's being a trustable
# source as all the secrets will pass throug their endpoint! (but hey, no VPN!)
# source as all the secrets will pass through their endpoint! (but hey, no VPN!)
resource "aws_security_group" "cloudflare-http" {
name_prefix = "cloudflare-http-"
description = "Allow HTTP/s only to CloudFlare"
......
......@@ -16,7 +16,7 @@ resource "cloudflare_record" "qm64_tech_vault" {
value = aws_instance.vault.public_ip
# By proxying it we do not expose the IP but we also ensure that the IP
# changes are propagated "faster" than DNS cache. Be carefull with the TTL if
# changes are propagated "faster" than DNS cache. Be careful with the TTL if
# proxy is disabled. :-)
ttl = "1"
proxied = true
......
......@@ -4,7 +4,7 @@
# This allows the instance to access the s3 bucket
###
# Prepare Vautl configuration file with teh AWS S3 bucket details
# Prepare vault configuration file with teh AWS S3 bucket details
data "template_file" "vault_conf" {
template = "${file("${path.module}/templates/vault-config.hcl.tpl")}"
vars = {
......@@ -14,7 +14,7 @@ data "template_file" "vault_conf" {
}
}
# Inject Vault confgiuration file into the cloud-init file. :-)
# Inject Vault configuration file into the cloud-init file. :-)
data "template_file" "cloud_init" {
template = "${file("${path.module}/templates/cloud-init.tpl")}"
vars = {
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment