Skip to content

martyn-meister/secrets-store-csi-driver-provider-1password

 
 

Repository files navigation

1Password Provider for Secret Store CSI Driver

Note: this is hacky code!

I did this work during something called innovation week, a meisterlabs concept much like a hackday, so it needs improvement.

This provider is very much the GCP provider hacked apart and the GCP secret manager parts pulled out and replaced with 1password connect features.

Flow diagram

flowchart TD
    A[Pod needing secret] --> B[SecretProviderClass]
    C[csi-secrets-store] -->M
    B --> M[Pod gets secrets mounted]
    C --> D[Plugin: csi-secrets-store-1password-provider]
    Y[This repo] --> D
    style Y stroke:#f66,stroke-width:2px,stroke-dasharray: 5 5
    D --> C
    D -- auth token--> E[1Password Connect]
    E --> D
    E -- auth token--> F[1Password API]
    F --> E
Loading

Rest of this readme untouched yet

e2e

Google Secret Manager provider for the Secret Store CSI Driver. Allows you to access secrets stored in Secret Manager as files mounted in Kubernetes pods.

Install

  • Create a new GKE cluster with Workload Identity or enable Workload Identity on an existing cluster.
  • Install the Secret Store CSI Driver v1.0.1 or higher to the cluster.
  • Install the Google plugin DaemonSet & additional RoleBindings:
kubectl apply -f deploy/provider-gcp-plugin.yaml
# if you want to use helm
# helm upgrade --install secrets-store-csi-driver-provider-gcp charts/secrets-store-csi-driver-provider-gcp

NOTE: The driver's rotation and secret syncing functionality is still in Alpha and requires additional installation steps.

Usage

The provider will use the workload identity of the pod that a secret is mounted onto when authenticating to the Google Secret Manager API. For this to work the workload identity of the pod must be configured and appropriate IAM bindings must be applied.

  • Setup the workload identity service account.
$ export PROJECT_ID=<your gcp project>
$ gcloud config set project $PROJECT_ID
# Create a service account for workload identity
$ gcloud iam service-accounts create gke-workload

# Allow "default/mypod" to act as the new service account
$ gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$PROJECT_ID.svc.id.goog[default/mypodserviceaccount]" \
    gke-workload@$PROJECT_ID.iam.gserviceaccount.com
  • Create a secret that the workload identity service account can access
# Create a secret with 1 active version
$ echo "foo" > secret.data
$ gcloud secrets create testsecret --replication-policy=automatic --data-file=secret.data
$ rm secret.data

# grant the new service account permission to access the secret
$ gcloud secrets add-iam-policy-binding testsecret \
    --member=serviceAccount:gke-workload@$PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/secretmanager.secretAccessor
  • Try it out the example which attempts to mount the secret "test" in $PROJECT_ID to /var/secrets/good1.txt and /var/secrets/good2.txt
$ ./scripts/example.sh
$ kubectl exec -it mypod /bin/bash
root@mypod:/# ls /var/secrets

Security Considerations

This plugin is built to ensure compatibility between Secret Manager and Kubernetes workloads that need to load secrets from the filesystem. It also enables syncing of those secrets to Kubernetes-native secrets for consumption as environment variables.

When evaluating this plugin consider the following threats:

  • When a secret is accessible on the filesystem, application vulnerabilities like directory traversal attacks can become higher severity as the attacker may gain the ability to read the secret material.
  • When a secret is consumed through environment variables, misconfigurations such as enabling a debug endpoint or including dependencies that log process environment details may leak secrets.
  • When syncing secret material to another data store (like Kubernetes Secrets), consider whether the access controls on that data store are sufficiently narrow in scope.

For these reasons, when possible we recommend using the Secret Manager API directly (using one of the provided client libraries, or by following the REST or GRPC documentation).

Contributing

Please see the contributing guidelines.

Support

This is not an officially supported Google product.

For support please search open issues here, and if your issue isn't already represented please open a new one. Pull requests and issues will be triaged weekly.

About

1Password Manager provider for the Secret Store CSI Driver.

Resources

License

Code of conduct

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Go 84.4%
  • Shell 10.2%
  • Makefile 3.6%
  • Dockerfile 1.8%