Today, I would like to discuss secrets and GitOps in the K8S world.

Some of my friends who are not DevOps/SRE engineers and most developers asked me too many times how to store Secrets/API keys/environment variables within the deployment process.

I hope this article will help to understand with a trivial explanation of the basics of how-to store secrets in the deployment process in the GitOps Way.

First things first

Plan of our journey:

• a small introduction about GitOps
• deploy k8s cluster ( EKS )
• encrypt sensitive data ( SOPS )
• deploy ArgoCD ( GitOps tool )
• deploy our application in the GitOps way
• inference

GitOps and why it is so important

Let’s imagine you have some Git repo and deploy your application into Kubernetes via Jenkins, AKA IaC style (Infrastructure as a code). At first look, this architecture is magnificent. We have stored our code in repo, and we deploy it via any CI\CD tool.

But why is GitOps so major? The answer to that question lies in how Kubernetes API works.

When you apply something into Kubernetes, the API will make you aware that the syntax is acceptable or not. If it’s OK, it will give you the lowdown that your resources are declaratively written. Kubernetes will deploy everything you declared.

But the first problem is that k8s does not guarantee that and the second one is that if somebody deletes/change/update information about any component or resource, you will never know until it is late.

The GitOps way implies that what is in the repo will be in Kubernetes. It literally syncs the states between your repo and Kubernetes. If an unspecified person changes something in Kubernetes ( delete or update config map, for example ), the GitOps tool will sync state and overwrite changes. It works in both ways.

#kubernetes #gitops #security #sops #devops #devops-security #devops-tools #hackernoon-top-story