Kondukto AWS DevOps Transformation

Kondukto is an AppSec Orchestration & Correlation (ASOC) platform that integrates with DevSecOps tools used by organizations to offer an automated and centralized vulnerability management process. Kondukto is there for any team that wants to build a vendor-agnostic security program that can scale at DevOps speed in the ever-accelerating world of software development and DevOps. Kondukto easily connects with all of the security, DevOps, collaboration, and secure coding training tools to unify existing vulnerabilities and turn them into actionable items.

The customer aims for security to be a set of processes that are easily integrated into existing infrastructures, not a barrier to agile development.
Their existing setup was running on docker swarm and cannot scale as expected and don’t have enough insights over orchestration with logging and monitoring.

Kondukto wanted to keep its dynamically growing environment on AWS scalable seamlessly, with all the security best practices, yet stays up to date with new security threats. They seek for an orchestration solution to get the best performance at an acceptable cost.

Customer Challenge

While orchestrating, they needed a system that could be scaled up in moments of unexpected load. Also, they needed to create an isolated area for customers subject to certain regulations, and this required a solution in which the containerized application could run. In this system, the isolated resources of each customer should also be scaled when necessary without a performance drop.

Since it plays a critical role in the workloads of its own customers, there was a need for an infrastructure that could constantly monitor the health of the Kondukto workload and self-healing.

Partner Solution

As BC4M we worked closely with the Kondukto Team in this process in order to understand their needs in the best way and to offer them the most accurate solutions with current technologies.

Our first action was recreating the Amazon Virtual Private Cloud (VPC) structure. We split private & public subnets based on zones. For private subnets to reach the services outside of our VPC, we used NAT gateways with elastic IP addresses. To control where network traffic is directed, we defined the routes and made the required changes for route tables. To architect an infrastructure with tightened security in the AWS, we limited access to the resources with security groups by specifying rules managing the inbound traffic to the EC2 instances.

For hosting the applications, we suggested and Kondukto approved to use of AWS Elastic Kubernetes Service (EKS) for the sense that it was the most suitable service as per the requirements and necessities. EKS cluster and node groups are positioned on the private subnets to host applications privately. Because the applications were hosted on the private subnets, ALB-ingress and ALB are provided for external access. We used the ALB-ingress controller for segmented external access over the EKS.

In the containerization stage, we begin fine-tuning and migrating existing Dockerfiles. Utilizing the ECR’s “Scan on push” feature we accumulate image security vulnerabilities and take actions to minimize them. We define container entry points according to best practices. We integrate APM tool agents on application containers and collect application performance metrics.

For data protection, we implement the AWS Backup service which offers cost-effective, fully managed, policy-based data protection to take daily backups of instance workload. In this implementation, the server whose backup is requested needs to be tagged, and it also needs to be tagged according to the desired backup policy.

We also provided AWS Inspector implementation for the security of instance workload. With AWS Inspector, Kondukto acquires an automated vulnerability management service that continually scans their instance workload for software vulnerabilities and unintended network exposure. This implementation also locates the target EC2 instance through the tags, performs the necessary scans, and shares its vulnerability findings with Kondukto. Based on the information obtained from these scans, a hardened image was created and this hardened image is used at the point where the instance workload will be scaled.

In order to meet Kondukto’s need for MongoDB, Mongo Atlas was set up in accordance with best practices. In this setup, a VPC Peering connection has been made so that the private network can be used.

We integrated CI/CD operations in order to deploy all applications running on the EKS cluster on a continuous and uninterrupted basis. We also configured CI/CD pipelines over GitLab CI to build and deploy applications. We created self-hosted GitLab runners as private on-demand EC2 instances and configured CI/CD pipelines to run on these self-hosted runners. We also used git-flow for CI/CD pipelines to incorporate the development life cycle with the CI/CD process. In the CI part of the pipeline, we build container images and push them to the ECR repository. In the CD part, we use helm charts for stable and effortlessly configured deployment processes of the images which were pushed to the ECR repository on the CI part.

To sustain system availability, we gather and track resource metrics on the CloudWatch service. We defined alerts to notify the team if a problem occurred and we created an alert flow mechanism with the help of the AWS ChatBot and AWS SNS services.

We collect logs on the AWS OpenSearch cluster in one region by using Logstash and Fluentd. We keep all the logs of the application running on a multi-regional structure on a centralized logging structure, making it easier to detect in case of issues and speeding up the development processes.

Results and Benefits

Together with our newly devised infrastructure and CI/CD approach, Kondukto has achieved an additionally secure, cost-optimized, highly available, scalable, and automated system. Kondukto is running its application in three different regions with the same standards. Similarly, the capability of monitoring applications and receiving alerts based on application and system metrics are increased and application and system logs are being stored on the central logging system.