external-secrets VS kube-score

Something I personally like about EKS is the Amazon Controllers for Kubernetes nowadays they would more preoperly be called 'operators' like the (non AWS and non AWS specific) External Secrets Operator. Essentially you delegate your cluster to create external resources elsewhere on your behalf based on annotations in your deployment.

Vault is extremely complex and heavy for my tastes, and Bitwarden Secrets Manager implementation AFAIU is not open source and not suitable for self-hosting. I like that both can be easily integrated with External Secrets for kubernetes secrets management.

Store the Secrets in a vault like Hashicorp Vault, AWS Secrets Manager, GCP Secret Manager, etc., and then use an operator like External Secrets Operator to add them to your K8s cluster.

External Secrets is an operator that integrates external KMS such as Hashicorp Vault or those of the major cloud providers. It reads secrets from the external APIs and injects them into Kubernetes secrets. The operator is a new implementation after the merge of similar projects from GoDaddy and ContainerSolutions.

I use Kubernetes-External-Secrets https://github.com/external-secrets/external-secrets with aws parameter store

This is taken from: https://github.com/zegl/kube-score/blob/master/README_PROBES.md and I have read the same opinions elsewhere.

A developer's workflow should anyway deploy to a real, or close-to-production Kubernetes cluster before opening a merge request with the finished change. That means the developer definitely sees upfront if the manifest is super wrong. Tools like kube-score (which is quite opinionated), kubeval or OPA rules can help in addition to keep things consistent and secure. For such a developer workflow, I recommend Skaffold since it mostly just wraps Docker, kubectl and the templating tool you're using (e.g. kustomize/helm).

apps/v1/Deployment semaphore-demo-ruby-kubernetes 💥 [CRITICAL] Container Resources · semaphore-demo-ruby-kubernetes -> CPU limit is not set Resource limits are recommended to avoid resource DDOS. Set resources.limits.cpu · semaphore-demo-ruby-kubernetes -> Memory limit is not set Resource limits are recommended to avoid resource DDOS. Set resources.limits.memory · semaphore-demo-ruby-kubernetes -> CPU request is not set Resource requests are recommended to make sure that the application can start and run without crashing. Set resources.requests.cpu · semaphore-demo-ruby-kubernetes -> Memory request is not set Resource requests are recommended to make sure that the application can start and run without crashing. Set resources.requests.memory [CRITICAL] Container Image Pull Policy · semaphore-demo-ruby-kubernetes -> ImagePullPolicy is not set to Always It's recommended to always set the ImagePullPolicy to Always, to make sure that the imagePullSecrets are always correct, and to always get the image you want. [CRITICAL] Pod NetworkPolicy · The pod does not have a matching NetworkPolicy Create a NetworkPolicy that targets this pod to control who/what can communicate with this pod. Note, this feature needs to be supported by the CNI implementation used in the Kubernetes cluster to have an effect. [CRITICAL] Pod Probes · Container is missing a readinessProbe A readinessProbe should be used to indicate when the service is ready to receive traffic. Without it, the Pod is risking to receive traffic before it has booted. It's also used during rollouts, and can prevent downtime if a new version of the application is failing. More information: https://github.com/zegl/kube-score/blob/master/README_PROBES.md [CRITICAL] Container Security Context · semaphore-demo-ruby-kubernetes -> Container has no configured security context Set securityContext to run the container in a more secure context. v1/Service semaphore-demo-ruby-kubernetes-lb ✅

Link : https://github.com/zegl/kube-score