Update our future plans
This commit is contained in:
@@ -5,22 +5,7 @@ I'll try to include any pertinent documentation here in the tooling I use or the
|
||||
|
||||
|
||||
#### Upcoming
|
||||
Initially we'll try to migrate our services from a docker compose and into a reproducible and controlled deployment scheme here. I'll also likely break this into its own repo and instead reference it as a submodule in our dotfiles (because it makes far more sense that way).
|
||||
|
||||
I also would like to swap the Docker repo used to be a generated [Harbor](https://goharbor.io/) one (due to the time constraints this would add I'll cope).
|
||||
For now with an .env file set up with your PAT token for [Dockerhub](https://hub.docker.com) and the repo set to `gigiaj/`
|
||||
```
|
||||
echo "$DOCKERHUB_PAT" | docker login --username gigiaj --password-stdin
|
||||
```
|
||||
|
||||
Plan to give OpenBao a single set of Wasabi IAM creds. Then OpenBao can be used to manage users and perms. Then we can make a role inside Bao.
|
||||
|
||||
I plan to start by giving OpenBao a single set of Wasabi IAM credentials. This will be the only time I need to do that. Once Bao has those credentials, it will be able to manage users and permissions for me automatically. For example, I might call it project alpha. I will link that role to a Wasabi policy that defines what kind of access it should have, like permission to read and write to buckets that start with project alpha.
|
||||
|
||||
That way when I need to Ican authenticate with Bao and ask for credentials tied to that role. Bao can then create a new IAM user in Wasabi, attach the correct policy, and generate temporary access keys. These keys are short-lived. This way we access storage, and once the time is up, Bao will automatically revoke the credentials and delete the user.
|
||||
This setup will give more secure, on demand access to Wasabi without having to manage IAM users or worry about long term credentials.
|
||||
|
||||
Also the chart-opts in K8s can be simplified as we don't need to do the odd-wrapping we are currently doing and instead can provide the ability to pull secrets from the opts declaration themselves by making them a function that needs to resolve first.
|
||||
Break this into three repos. IaC, the Pulumi CLJS library, and my dot files. We'll also be moving data from our old instances to the new IaC managed cluster. c: End goals.
|
||||
|
||||
#### Goals
|
||||
The long term goal is for this to be a mostly uninteractive, to completion set up of my cloud services. Since it'll be IaC should I ever choose down the road to migrate certain ones to local nodes I run then that effort should also be more or less feasible.
|
||||
@@ -172,7 +157,7 @@ kubectl get secret <secrets-name> -n <namespace> -o jsonpath='{.data}' | jq 'map
|
||||
```
|
||||
kubectl get secret <SECRET-RESOURCE-NAME> -n harbor -o jsonpath='{.data}' | jq 'map_values(@base64d)'
|
||||
-----
|
||||
|
||||
kubectl get secret harbor-creds-secrets -n harbor -o jsonpath='{.data}' | jq 'map_values(@base64d)'
|
||||
|
||||
|
||||
Generating an RSA PKCS#1 key with openssl:
|
||||
@@ -199,4 +184,9 @@ Hashing the htpassword
|
||||
```
|
||||
npm install bcryptjs
|
||||
node -e 'console.log("admin:" + require("bcryptjs").hashSync("password", 10))'
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
https://www.pulumi.com/registry/packages/docker-build/api-docs/image/
|
||||
https://www.pulumi.com/registry/packages/docker/api-docs/buildxbuilder/#create
|
||||
|
||||
|
||||
Reference in New Issue
Block a user