Linkedsecrets can create Kubernetes secrets types bellow:
Docker config secrets type is auto-detected by Linkedsecrets based on cloud secrets fields. If your cloud secrets have at least fields “docker-username” and “docker-password”, Linkedsecrets will create a Kubernetes secrets with type “kubernetes.io/dockerconfigjson”.
Follow bellow all supported cloud secrets fields to create Kubernetes Docker config secrets:
If “docker-server” field is ommited, Linkedsecrets will assign default value “https://index.docker.io/v1/”.
To create secrets with base64 encoded data, just encode file content and add to secrets field.
Linkedsecrets will decode data and create Kubernetes secret. If data decoded results in a non UTF8 string, undecoded data will be used to create Kubernetes secret.
Configure kubeideas Helm repository locally:
helm repo add kubeideas https://kubeideas.github.io/linkedsecrets/
Search repository:
helm search repo kubeideas
Before install Linkedsecrets Helm chart, install manually Linkedsecrets CRD:
kubectl apply -f https://github.com/kubeideas/linkedsecrets/releases/download/v0.8.4/security.kubeideas.io_linkedsecrets.yaml
Google Service account with permission on role Secret Manager Secret Accessor.[IMPORTANT] Avoid security issues and grant access only to secrets strictly relevant to your Kubernetes cluster.
helm upgrade --install \
linkedsecrets \
--create-namespace=true \
--namespace=<LINKEDSECRETS-NAMESPACE> \
--set gcp.enabled=true \
--set-file gcp.credentialFile="path/<GCP_CREDENTIALS_FILE>.json" \
kubeideas/linkedsecrets
Create AWS user with permissions to read secrets.
[IMPORTANT] Avoid security issues and grant access only to secrets strictly relevant to your Kubernetes cluster.
helm upgrade --install \
linkedsecrets \
--create-namespace=true \
--namespace=<LINKEDSECRETS-NAMESPACE> \
--set aws.enabled=true \
--set aws.awsAccessKeyId="<AWS_ACCESS_KEY_ID>" \
--set aws.awsSecretAccessKey="<AWS_SECRET_ACCESS_KEY>" \
kubeideas/linkedsecrets
Register an App on Azure Active directory with permissions to get and list secrets.
[IMPORTANT] Avoid security issues and grant access only to secrets strictly relevant to your Kubernetes cluster.
helm upgrade --install \
linkedsecrets \
--create-namespace=true \
--namespace=<LINKEDSECRETS-NAMESPACE> \
--set azure.enabled=true \
--set azure.azureTenantId="<AZURE_TENANT_ID>" \
--set azure.azureClientId="<AZURE_CLIENT_ID>" \
--set azure.azureClientSecret="<AZURE_CLIENT_SECRET>" \
kubeideas/linkedsecrets
Create IBM Service Api Key with permission on role SecretsReader.
helm upgrade --install \
linkedsecrets \
--create-namespace=true \
--namespace=<LINKEDSECRETS-NAMESPACE> \
--set ibm.enabled=true \
--set ibm.ibmServiceApiKey="<IBM_SERVICE_API_KEY>" \
kubeideas/linkedsecrets
This example bellow enables Google Secret Manager and AWS Secrets Manager access, but any combination is allowed.
[IMPORTANT] Avoid security issues and grant access only to secrets strictly relevant to your Kubernetes cluster.
helm upgrade --install \
linkedsecrets \
--create-namespace=true \
--namespace=<LINKEDSECRETS-NAMESPACE> \
--set gcp.enabled=true \
--set-file gcp.credentialFile="path/<GCP_CREDENTIALS_FILE>.json" \
--set aws.enabled=true \
--set aws.awsAccessKeyId="<AWS_ACCESS_KEY_ID>" \
--set aws.awsSecretAccessKey="<AWS_SECRET_ACCESS_KEY>" \
kubeideas/linkedsecrets
kubectl get pods -n <LINKEDSECRETS-NAMESPACE>
kubectl explain linkedsecret.spec
kubectl explain linkedsecret.status
Commom fields are applicable for all supported Cloud providers:
apiVersion: security.kubeideas.io/v1
kind: LinkedSecret
metadata:
name: <LINKEDSECRET-NAME>
spec:
rolloutRestartDeploy: <DEPLOYMENT-NAME>
keepSecretOnDelete: <true | false>
secretName: <KUBERNETES-SECRET-NAME-CREATED-AND-MAINTAINED-BY-LINKEDSECRETS>
schedule: <"@every 10m" | ANY-OTHER-SYNCHRONIZATION-INTERVAL>
suspended: <true | false>
Set this field with deployment’s name which secret is maintained by LinkedSecrets. If any change is detected, Linkedsecrets will roll out all deployment’s pods automatically. This field can be omitted if you don’t whant to use this feature.
Set this field to true if you want to keep secret intact after Linkedsecret object is deleted. This field can be omitted if you don’t whant to use this feature.
This feature is particularly useful in upgrade situations.
It defines the Kubernetes Secret name that will be created and maintained by Linkedsecrets.
Linkedsecrets synchronization is executed based on schedule. Pre-defined cron expressions and Classic cron expressions are accepted.
| Expression | Description |
|---|---|
| “@every 300s” | Run every 5 minutes |
| “@every 10m” | Run every 10 minutes |
| “@every 5m30s” | Run every 5 minutes and 30 seconds |
| “@hourly” | Run once an hour, beginning of hour |
| “@daily” | Run once a day, midnight |
| Expression | Description |
|---|---|
| “*/20 * * * * *” | Run every 20 seconds |
| “0 */5 * * * *” | Run every 5 minutes |
| “0 0 * * * *” | Run once an hour, beginning of hour |
| “0 0 0 * * *” | Run once a day, midnight |
[IMPORTANT] Have in mind that Cloud will charge you on each secret created and access operations. Having said that, tune the schedule accordingly.
Use this field any time you need to stop data synchronization between Kubernetes Secret and Cloud Secret.
Click here for GCP details and examples.
Click here for AWS details and examples.
Click here for Azure details and examples.
Click here for IBM details and examples.
If you intend to keep applications secrets intact after remove Linkedsecrets objects, do not forget to enable option "keepSecretOnDelete" on all of them before.
kubectl patch lns <NAME> --type='json' -p='[{"op": "replace", "path": "/spec/keepSecretOnDelete", "value":true}]' -n <NAMESPACE>
kubectl delete lns --all --all-namespaces
helm -n <LINKEDSECRETS-NAMESPACE> delete linkedsecrets
kubectl delete -f https://github.com/kubeideas/linkedsecrets/releases/download/v0.8.4/security.kubeideas.io_linkedsecrets.yaml
kubectl delete namespace <LINKEDSECRETS-NAMESPACE>