feat: add OpenStack Keystone to be installed

Adds the ability to install OpenStack Keystone into the cluster.

README.md

@@ -59,4 +59,7 @@ kubectl apply -k components/01-secrets/
 kubectl -n argocd apply -k apps/components/
 ```
 
-ArgoCD should successfully get everything deployed.
+ArgoCD should successfully get Nautobot deployed. Now come the OpenStack
+components which aren't working with GitOps methods at this time.
+
+[Install Keystone](./components/10-keystone/README.md)

apps/components/keystone.yaml

@@ -0,0 +1,16 @@
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: keystone
+spec:
+  project: understack
+  source:
+    repoURL: https://github.com/rackerlabs/understack.git
+    path: components/10-keystone/
+    targetRevision: HEAD
+  destination:
+    server: "https://kubernetes.default.svc"
+    namespace: openstack
+  syncPolicy:
+    automated:
+      selfHeal: true

apps/components/kustomization.yaml

@@ -11,3 +11,4 @@ resources:
   - memcached.yaml
   - postgres-db.yaml
   - nautobot.yaml
+  - keystone.yaml

components/01-secrets/README.md

@@ -81,6 +81,48 @@ kubeseal \
     -w components/01-secrets/encrypted-nautobot-redis.yaml
 ```
 
+## Keystone
+
+Generate the necessary secrets for OpenStack Keystone.
+
+```bash
+kubectl --namespace openstack \
+        create secret generic keystone-rabbitmq-password \
+        --type Opaque \
+        --from-literal=username="keystone" \
+        --from-literal=password="$($(git rev-parse --show-toplevel)/scripts/pwgen.sh)" \
+        --dry-run -o yaml > secret-keystone-rabbitmq-password.yaml
+kubectl --namespace openstack \
+        create secret generic keystone-db-password \
+        --type Opaque \
+        --from-literal=password="$($(git rev-parse --show-toplevel)/scripts/pwgen.sh)" \
+        --dry-run -o yaml > secret-keystone-db-password.yaml
+kubectl --namespace openstack \
+        create secret generic keystone-admin \
+        --type Opaque \
+        --from-literal=password="$($(git rev-parse --show-toplevel)/scripts/pwgen.sh)" \
+        --dry-run -o yaml > secret-keystone-admin.yaml
+kubectl --namespace openstack \
+        create secret generic keystone-credential-keys \
+        --type Opaque \
+        --from-literal=password="$($(git rev-parse --show-toplevel)/scripts/pwgen.sh)" \
+        --dry-run -o yaml > secret-keystone-credential-keys.yaml
+```
+
+Now let's seal them.
+
+```bash
+for skrt in $(find . -name "secret-keystone*.yaml" -depth 1); do
+    encskrt=$(echo "${skrt}" | sed -e 's/secret-/components\/01-secrets\/encrypted-/')
+    kubeseal \
+        --scope cluster-wide \
+        --allow-empty-data \
+        -o yaml \
+        -f "${skrt}" \
+        -w "${encskrt}"
+done
+```
+
 ## Generate Kustomize for the Install
 
 Now generate the kustomize for this.

components/03-mariadb/kustomization.yaml

@@ -1,6 +1,7 @@
 ---
 apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
+
 resources:
   - mariadb-configmap.yaml
   - mariadb-instance.yaml

components/10-keystone/README.md

@@ -0,0 +1,52 @@
+# OpenStack Keystone
+
+So unfortunately OpenStack Helm doesn't publish helm charts that can be consumed like
+regular helm charts. You must instead clone two of their git repos side by side and
+build the dependencies manually. They additionally don't split out secrets but instead
+template them into giant config files or even executable scripts that then get stored
+as secrets, a clear violation of <https://12factor.net>. As a result we cannot store
+a declarative config of Keystone and allow users to supply their own secrets.
+
+Due to the above issues, for now we'll skip the ArgoCD ability for this deployment.
+
+## Get OpenStack Helm Ready
+
+You may have done this for another OpenStack component and can share the same
+git clones. This assumes you're doing this from the top level of this repo.
+
+```bash
+# clone the two repos because they reference the infra one as a relative path
+# so you can't use real helm commands
+git clone https://github.com/openstack/openstack-helm
+git clone https://github.com/openstack/openstack-helm-infra
+# update the dependencies cause we can't use real helm references
+./scripts/openstack-helm-depend-sync.sh keystone
+cd components/10-keystone
+```
+
+## Deploy Keystone
+
+Since we cannot refer to the secrets by name, we must look them up live from the cluster
+so that we can injected them into the templated configs. Upstream should really allow
+secrets to be passed by reference. As a result of this we cannot use GitOps to generate
+these charts and have them applied to the cluster.
+
+Secrets Reference:
+
+- openstack-default-user is created by the messaging-topology-operator which is
+  executed by the rabbitmq-queues component. The name stems from the RabbitMQ
+  cluster from the rabbitmq-cluster component. `${CLUSTER_NAME}-default-user`
+
+```bash
+helm --namespace openstack template \
+    keystone \
+    ./openstack-helm/keystone/ \
+    -f aio-values.yaml \
+    --set endpoints.identity.auth.admin.password="$(kubectl --namespace openstack get secret keystone-admin -o jsonpath='{.data.password}' | base64 -d)" \
+    --set endpoints.oslo_db.auth.admin.password="$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d)" \
+    --set endpoints.oslo_db.auth.keystone.password="$(kubectl --namespace openstack get secret keystone-db-password -o jsonpath='{.data.password}' | base64 -d)" \
+    --set endpoints.oslo_messaging.auth.admin.password="$(kubectl --namespace openstack get secret openstack-default-user -o jsonpath='{.data.password}' | base64 -d)" \
+    --set endpoints.oslo_messaging.auth.keystone.password="$(kubectl --namespace openstack get secret keystone-rabbitmq-password -o jsonpath='{.data.password}' | base64 -d)" \
+    --post-renderer $(git rev-parse --show-toplevel)/scripts/openstack-helm-sealed-secrets.sh \
+    | kubectl -n openstack apply -f -
+```