DoD-Platform-One / bigbang

BigBang the product
https://repo1.dso.mil/big-bang/bigbang
Apache License 2.0
153 stars 67 forks source link

Documentation Update #27

Open p1-repo-sync-bot[bot] opened 5 months ago

p1-repo-sync-bot[bot] commented 5 months ago

Hi BB team- I recently setup BB on GCP and wanted to provide some feedback to your documentation that might help future users. Please feel free to take it or leave it. Thanks!

  1. The docs mention a "Fork" button, but there is no "Fork" button on the BigBang Gitlab repo page. You need to download the repo as a tar.gz file and upload to your own repo in your Gitlab instance instead.

  2. If using a GCP KMS key, you can skip the section: "Create GPG Encryption Key". Instead, in your .sops.yaml file (note - this is a hidden file at the root of this directory) use this configuration instead of the GPG config:

    creation_rules:
    - encrypted_regex: '^(data|stringData)$'
    gcp_kms: <gcp resource name of key>

    Key resource name should look like: projects/{PROJECT_ID}/locations/global/keyRings/{KEY_RING_NAME}/cryptoKeys/{KEY_NAME}_**

If you get errors about the key not working, try re-logging in to GCP:

gcloud auth application-default login

And make sure you have the right project set:

gcloud config set project <project_id>

Also make sure you have these IAM roles on your GCP account:

roles/container.admin  
roles/iam.serviceAccountAdmin  

The KMS key also needs IAM permissions, and needs to be linked back to the flux-controller in the cluster. You need to create a service account and role binding, then manually annotate it:

kubectl annotate serviceaccount kustomize-controller --namespace flux-system iam.gke.io/gcp-service-account=flux-service-account@<project_id>.iam.gserviceaccount.com

GCP uses Workload Identity to allow the flux-controller to use the service account, good references for this setup are here. Make sure you enable Workload Identity on the cluster nodes:
GCP Docs
Medium Article

  1. When encrypting the bigbang-dev-cert.yaml file with SOPS as mentioned in the documentation, it creates an encrypted secrets file, but the original file is not deleted. I recommend mentioning the need to delete this file so secrets aren't committed an I'd recommend decrypting and encrypting in place:

    sops -d --in-place base/secrets.enc.yaml
    sops -e --in-place base/secrets.enc.yaml
  2. When creating the private-git secret, the docs say to use Repo1 username and password, but if you are using your own git repo outside of Repo1, then it's not Repo1 and I'd just make that more clear.

p1-repo-sync-bot[bot] commented 4 months ago

bb8-bot commented:

@andrewrisse this issue has been inactive for 30 days and is being labelled as ~stale. If this issue is still required please take action by removing the ~stale label and commenting with an update, status, or justification. If this issue is not required please close it or label it as ~delete-me. If no action is taken this issue will be auto closed in 60 days.