A Kubernetes operator that automatically maps what are stored in AWS SSM Parameter Store into Kubernetes Secrets.
aws-ssm-operator Custom Resources defines desired state of Kubernetes Secret fetched from SSM Parameter Store. Otherwise, parameterstore-controller controller monitors user's request and cached parameter values or credentials as plaintext into Kubernetes Secret.
You have to store configuration parameter or credentials into SSM Parameter Store.
Let's say, your application inside a Pod wish to connect to Aurora instances by using database user and password.
# Store database user with simple string
aws ssm put-parameter \
--name "/stg/foo-app/dbuser" \
--type "String" \
--value "dbuser" \
--overwrite
# Store database password encrypted with default KMS key
aws ssm put-parameter \
--name "/stg/foo-app/dbpassword" \
--type "SecureString" \
--value "dbpassword" \
--overwrite
# Store database user with simple string
aws ssm put-parameter \
--name "/stg/foo-app/user/dbuser" \
--type "String" \
--value "dbuser" \
--overwrite
# Store database password encrypted with default KMS key
aws ssm put-parameter \
--name "/stg/foo-app/password/dbpassword" \
--type "SecureString" \
--value "dbpassword" \
--overwriteSo, you can retrieve DB credentials by certain path like below:
$ aws ssm get-parameters-by-path --with-decryption --path /stg/foo-app
{
"Parameters": [
{
"Type": "String",
"Name": "/stg/foo-app/dbuser",
"Value": "foo-user"
},
{
"Type": "SecureString",
"Name": "/stg/foo-app/dbpassword",
"Value": "*****"
}
]
}In case of using EKS Cluster as your Kubernetes platform, attach AmazonSSMReadOnlyAccess policy or equivalent of that to Instance Profiles of EKS worker nodes.
# Setup Service Account
make deploy
# Verify that a Pod is running
kubectl get pod -l app=aws-ssm-operator --watch -n aws-ssmCreate an sample Paramter Store resource:
# Create an example Parameter Store resource by name
$ kubectl create -f example/parameterStoreRef/database-name.yaml
# Create an example Parameter Store resource by path
$ kubectl create -f example/parameterStoreRef/database-path.yaml
# Create an example Parameters Store resource by path
$ kubectl create -f example/parameterStoreRef/parameters.yamlIn case of using name reference, you can find your credentials in separate Secret resources as follows. The key to secret data is 'name' which is hardcoded and cannot be changed.
$ kubectl describe secret dbpassword
Name: dbpassword
Namespace: default
Labels: app=dbpassword
Annotations: <none>
Type: Opaque
Data
====
name: 9 bytes
$ kubectl describe secret dbuser
Name: dbuser
Namespace: default
Labels: app=dbuser
Annotations: <none>
Type: Opaque
Data
====
name: 7 bytesYou can reference secret data in your Deployment declaration as follows:
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
template:
spec:
containers:
- image: toversus/sample-app
env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: dbuser
key: name
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: dbpassword
key: nameIn case of putting parameters together under certain path, you can find your credentials in single Secret resource as follows. The key to secret data is last segment of path. The following example shows that your credentials are located in /stg/foo-app/dbuser and /stg/foo-app/dbpassword, so you can retrieve them by dbuser and dbpassword keys respectively.
$ kubectl describe secret foo-app
Name: foo-app
Namespace: default
Labels: app=foo-app
Annotations: <none>
Type: Opaque
Data
====
dbpassword: 10 bytes
dbuser: 6 bytesYou can reference secret data in your Deployment declaration as follows:
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app-pod
spec:
containers:
- name: sample-app
image: toversus/sample-app
envFrom:
- secretRef:
name: foo-app
restartPolicy: NeverIn case of putting parameters together from certain paths, you can find your credentials in single Secret resource as follows. The key to secret data is full path. The following example shows that your credentials are located in /stg/foo-app/user/dbuser and /stg/foo-app/password/dbpassword, so you can retrieve them by dbuser and dbpassword keys respectively.
$ kubectl describe secret foo-app-keys
Name: foo-app-keys
Namespace: default
Labels: app=foo-app-keys
Annotations: <none>
Type: Opaque
Data
====
dbpassword: 10 bytes
dbuser: 7 bytesYou can reference secret data in your Deployment declaration as follows:
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app-pod
spec:
containers:
- name: sample-app
image: toversus/sample-app
envFrom:
- secretRef:
name: foo-app-keys
restartPolicy: NeverTo clean up all the components:
make undeploy
kubectl delete -f example/ # enable docker buildkit engine
export DOCKER_BUILDKIT=1
make docker-buildInstallation for linux (Ubuntu)
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikubeDirect installation
sudo apt-get update
sudo apt-get install pip
pip install localstackHelm Installation
helm upgrade --install localstack localstack-repo/localstack minikube start export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services localstack)
export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
export LOCALSTACK_HOST="http://$NODE_IP"
export LOCALSTACK_PORT="$NODE_PORT" alias awslocal="AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_DEFAULT_REGION=us-east-1 aws --endpoint-url=${LOCALSTACK_HOST:-127.0.0.1}:${LOCALSTACK_PORT:-4566}" KUSTOMIZE_PROFILE=config/local make docker-build deployThe idea behind this project is fully based on mumoshu/aws-secret-operator. Thanks for your awesome work!