Kubernetes *

Secret Management and Why It’s Important

Hi! My name is Evgeny, and I work as a Lead DevOps at Exante. In this article, I will discuss the practical experience of setting up a high-availability HashiCorp Vault with a GCP storage backend and auto unseal in Kubernetes (K8s).

Our infrastructure used to consist of thousands of virtual and physical machines hosting our legacy services. Configuration files, including plain-text secrets, were distributed across these machines, both manually and with the help of Chef.

We decided to change the company’s strategy for several reasons: to accelerate code delivery processes, ensure continuous delivery, securely store secrets, and speed up the deployment of new applications and environments.

We decided to transition our product to a cloud-native model, which required us to change our approach to development and infrastructure. This involved refactoring our legacy services, adopting a microservices architecture, deploying services in cloud-based Kubernetes (K8s), and utilizing managed resources like Redis and PostgreSQL.

In our situation, everything needed to change—from applications and infrastructure to how we distribute configs and secrets. We chose Google as our cloud provider and HashiCorp Vault for secret storage. We've since made significant progress on this journey.

Why HashiCorp Vault?

There were several reasons:

За последнее время я вижу всё больше споров на тему двух популярных GitOps инструментов: Argo CD и Flux CD.

На самом деле я считаю такие споры необоснованными, потому что глубоко убеждён что внимания заслуживают оба инструмента и каждый из них хорош для решения своего круга задач.

В своей профессиональной деятельности я активно использую и тот и другой. Я хочу поделиться с вами своим мнением и кейсами использования. Надеюсь эта статья поможет вам выбрать наиболее подходящий инструмент под ваши нужды.

I'm Alex Movergan, DevOps team lead at Altenar. I focus on automation in general and on improving troubleshooting skills within my team. In this article, I'll share a captivating tale that revolves around Kubernetes, validation webhooks, kubespray, and Calico.

Join me on this DevOps journey as we explore real-world scenarios unraveling the intricacies of troubleshooting in a Kubernetes environment.

In previous post I've described an example of kogito-based microservice on quarkus in native mode, containing one embedded pmml model with decision tree. While it can be successfully used for prototyping purposes, in the real life microservice might contain several prediction models. From the first view I've got an impression, that inclusion of several models should be a trivial extension of the prototype with one model. We were completely wrong in our assumption, that's the reason, why I've decided to write this post. Another reason, is absence of guides, in which 2 (or more models) are put inside DMN diagrams in kogito framework.

Very often we've heard that some frameworks fit together so good, that they are considered as "match made in heaven". In this article I would like to share our experience regarding integration of those frameworks.

In any history textbooks, the modern time has already been called the time of the next change of the industrial structure or the fourth industrial revolution (Industry 4.0). The main role, in this case, is given to information and IT systems. In an attempt to reduce the cost of IT infrastructure, unify and accelerate the process of developing IT solutions, humanity first invented "clouds" in order to replace traditional data centers, and then containers to replace virtual machines.

Clearly, containers appear more vulnerable from a security point of view. What are the advantages of containerization over virtualization? In fact, there are quite a lot of them:

• the possibility of more flexible use of available resources (no need to backup them as in the case of virtual machines);

• the ability to save resources (no need to spend them on many copies of the OS for each virtual machine);

• no delays at startup (just start of the process is almost instantaneous compared to the time needed to load the virtual machine);

• the interaction between processes, even if isolated, is much easier to implement when needed than between virtual machines. That is how, by the way, came the concept of microservices, which has recently become very popular.

All of the above led to the very rapid development of container technologies, despite the recurring problems with the security of already deployed container cloud systems, their hacks, and data leaks. Accordingly, the work on strengthening container security is also continuing. This is what will be discussed further in this article.

I'd like to share my story about migration an application to Openshift. Also, as a result, I will compare some of the most popular solutions and tools for managing your application inside Openshift. It is the transcription of my presentation at kubernetes SPB meetup #3.

If you are working with Kubernetes environment then you probably make use of several existing templating tools, some of them being a part of package managers such as Helm or Ksonnet, or just templating languages (Jinja2, Go template etc.). All of them have their own drawbacks as well as advantages and we are going to go through them and write our own tool that will try to combine the best features.