Update our future plans

iac/README.md

@@ -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).
+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.
-
-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.
 
 #### 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
+