mirrors/90DaysOfDevOps
1
0
Fork 0
mirror of https://github.com/MichaelCade/90DaysOfDevOps.git synced 2024-12-22 21:43:13 +07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #399 from btkrausen/update-day-36

Browse Source 
fixing typo and adding links
This commit is contained in:
Michael Cade 2023-04-06 18:33:37 +01:00 committed by GitHub
commit f833ee35fc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
2023.md
View File

@ -87,7 +87,7 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
### Secrets Management
- [✔️] 🕵 35 > [Understanding the Importance of Secrets Management](2023/day35.md)
- [] 🕵 36 > [](2023/day36.md)
- [✔️] 🕵 36 > [Securing Secrets with HashiCorp Vault](2023/day36.md)
- [] 🕵 37 > [](2023/day37.md)
- [] 🕵 38 > [](2023/day38.md)
- [] 🕵 39 > [](2023/day39.md)

4
2023/day36.md
View File

@ -23,7 +23,7 @@ Beyond installing Vault, there are additional requirements that you'll want to c
 
As somebody who has worked on Vault for over six years and a dedicated member of the HashiCorp community, I have all of this on [my GitHub](https://github.com/btkrausen/hashicorp) for your consumption. These are files that I use for production-level deployments, so they are tried and tested in the real world. Feel free to use these as a starting point and customize them per your needs.
 
> If all this seems confusing, you can check out my [Getting Started with HashiCorp Vault Course] (https://btk.me/v) to learn all about these configurations (and so much more!), along with getting access to hands-on labs.
> If all this seems confusing, you can check out my [Getting Started with HashiCorp Vault Course](https://btk.me/v) to learn all about these configurations (and so much more!), along with getting access to hands-on labs.
 
## Vault is Up and Running. What's Next?
 
@ -45,3 +45,5 @@ stanza).
* Using a root token gives you complete, unrestricted access to anything in Vault. The root token is highly privileged and should NOT be shared. In fact, it is not evaluated against any Vault policies. Therefore, it is recommended to use the root token to perform the initial configuration, namely auth methods, and then the token should be revoked. [Another root token can be generated](https://youtu.be/rcQsNinVl0Y) in the future if needed.
 
* A single Vault node may be sufficient for lab environments if redundancy and high availability aren't a concern. If service uptime is essential, use a minimum of 3 nodes (assuming integrated storage). I recommend five nodes for production clusters to give you n + 2 redundancy, meaning you can lose up to two nodes, and the Vault service remains functional.
See you on [Day 37](day37.md).