tree: 8c8341682b4a2844600dffeee513da0d4c9eea76 [path history] [tgz]
  1. add-secret-from-directory.sh
  2. add-secret-from-stdin.sh
  3. add-service-account-from-stdin.sh
  4. add-service-account.sh
  5. apply-all-secrets-to-cluster.sh
  6. apply-secret-to-cluster.sh
  7. config.sh
  8. copy-between-clusters.sh
  9. copy-from-cluster.sh
  10. copy-secret-between-clusters.sh
  11. delete-secret.sh
  12. download-secret.sh
  13. edit-secret.sh
  14. generate-new-key-for-service-account.sh
  15. get-secret-at-path.sh
  16. get-secret.sh
  17. init-berglas.sh
  18. list-secrets-by-cluster.sh
  19. list-secrets.sh
  20. README.md
  21. rotate-keys-for-skia-corp-sa.sh
kube/secrets/README.md

Secrets

Secrets for all clusters are stored encrypted in Google Cloud Storage with the keys managed via Google KMS. We use the berglas tool to manage the encrypted information.

There is a command to copy secrets between cluster directories and a command to apply all secrets for a cluster, thus making it easy to spin up a new cluster.

All commands move the secrets through stdin/stdout, except edit-secrets.sh which uses a temporary ramdisk to store the files which gets unmounted immediately after editing. In all cases secrets never sit on the developer's drive.

The add-service-account.sh script emits the full service account email address on stdout, which is useful for scripts that need to do further processing, such as giving that service account access to a specific PubSub topic.

Access control

Files are accessible only by members of skia-root@google.com.

To create local credentials that are usable by berglas, you should run:

    gcloud auth application-default login

Also make sure that the GOOGLE_APPLICATION_CREDENTIALS environment variable isn't set.

Configuration

The configuration is stored in config.sh. If you change the bucket or project, you will have to re-run init-berglas.sh.

Format

All secrets are stored as base64-encoded kubernetes secrets serialized as YAML.

Secrets are stored in a sub-directory in Google Cloud Storage, the name of which is the name of the cluster they are used in.

We will use the cluster name etc as a special cluster name for secrets that aren't used in k8s, but are still secrets we need easy access to, such as the authorized_keys file we distribute to all the jumphosts.

Naming

The GKE cluster names as returned from kubectl config current-context aren't the normal names like skia-public that we are used to, so there are helper functions in config.sh to translate between common names and the values returned from current-context.