Operator which manages Kubernetes Secret Resources created from user defined SopsSecrets
CRs, inspired by Bitnami SealedSecrets and
sops. SopsSecret CR defines multiple
kubernetes Secret resources. It supports managing kubernetes Secrets with
annotations and labels, that allows using these kubernetes secrets as Jenkins Credentials.
The SopsSecret resources can be deployed by Weaveworks Flux GitOps CD and
encrypted using sops for AWS, GCP, Azure or
on-prem hosted kubernetes clusters. Using sops
greatly simplifies changing
encrypted files stored in git
repository.
- sops - 3.5.0
- operator-sdk 0.13.0
- golang - 1.13.4
- Create KMS key
- Create AWS Role which can be used by operator to decrypt CR data structure, follow sops documentation
- Deploy CRD:
kubectl apply -f deploy/crds/isindir_v1alpha1_sopssecret_crd.yaml
NOTE: to grant access to aws for
sops-secret-operator
- kiam can be used.
- Deploy helm chart:
kubectl create namespace sops
helm upgrade --install sops chart/sops-secrets-operator/ \
--namespace sops
For instructions on howto configure PGP keys for operator, see Preparing GPG keys
Then install operator:
kubectl create namespace sops
kubectl apply -f docs/gpg/1.yaml --namespace sops
kubectl apply -f docs/gpg/2.yaml --namespace sops
kubectl apply -f chart/crds/isindir_v1alpha1_sopssecret_crd.yaml
helm upgrade --install sops chart/sops-secrets-operator/ \
--namespace sops --set gpg.enabled=true
- create SopsSecret file, for example:
cat >jenkins-secrets.yaml <<EOF
apiVersion: isindir.github.com/v1alpha1
kind: SopsSecret
metadata:
name: example-sopssecret
spec:
secret_templates:
- name: jenkins-secret
labels:
"jenkins.io/credentials-type": "usernamePassword"
annotations:
"jenkins.io/credentials-description" : "credentials from Kubernetes"
data:
username: myUsername
password: 'Pa$$word'
- name: some-token
data:
token: Wb4ziZdELkdUf6m6KtNd7iRjjQRvSeJno5meH4NAGHFmpqJyEsekZ2WjX232s4Gj
EOF
- Encrypt file using
sops
and AWS kms key:
sops --encrypt \
--kms 'arn:aws:kms:<region>:<account>:alias/<key-alias-name>' \
--encrypted-suffix='_templates' jenkins-secrets.yaml \
> jenkins-secrets.enc.yaml
- Encrypt file using
sops
and GCP KMS key:
sops --encrypt \
--gcp-kms 'projects/<project-name>/locations/<location>/keyRings/<keyring-name>/cryptoKeys/<key-name>' \
--encrypted-suffix='_templates' jenkins-secrets.yaml \
> jenkins-secrets.enc.yaml
- Encrypt file using
sops
and Azure Keyvault key:
sops --encrypt \
--azure-kv 'https://<vault-url>/keys/<key-name>/<key-version>' \
--encrypted-suffix='_templates' jenkins-secrets.yaml \
> jenkins-secrets.enc.yaml
- Encrypt file using
sops
and PGP key:
sops --encrypt \
--pgp '<pgp-finger-print>' \
--encrypted-suffix='_templates' jenkins-secrets.yaml \
> jenkins-secrets.enc.yaml
Note: Multiple keys can be used to encrypt secrets. At the time of decryption access to one of these is needed. For more information see
sops
documentation.
Mozilla Public License Version 2.0
sops-secrets-operator
is not following Kubernetes OpenAPI naming conventions, because of that it is not possible to generate OpenAPI definition usingoperator-sdk generate openapi
command. This is due to the fact thatsops
generates substructures in encrypted file with incompatible to OpenAPI names (containing underscore symbols, where it should becamelCase
for OpenAPI compatibility).sops-secrets-operator
is not using standardsops
library decryption interface function, modified upstream function is used to decrypt data which ignoresenc
signature field insops
metadata. This is due to the fact that when Kubernetes resource is applied it is always mutated by Kubernetes, for example resource version is generated and added to the resource. But any mutation invalidatessops
metadataenc
field and standard decryption function fails.
Projects and tools inspired development of sops-secrets-operator
: