As organizations move more of their operations to the cloud, the need for secure and compliant infrastructure becomes increasingly important. With the rapid pace of cloud adoption, it’s crucial to have a tool that can help you ensure that your cloud infrastructure is configured securely and in compliance with best practices. So in today’s blog, we will be talking about a solution for all these problems which is Checkov.
What is Checkov?
Checkov is a tool that helps developers and operations teams ensure that their infrastructure is secure and compliant with best practices. It does this by automatically scanning infrastructure as code (IaC) and runtime environments for issues that could potentially lead to security vulnerabilities or compliance failures. Checkov works by scanning code written in various IaC languages (such as Terraform, CloudFormation, and ARM templates) and looking for patterns that could indicate security or compliance risks. It can also be integrated into a continuous integration/continuous deployment (CI/CD) pipeline, allowing it to scan code automatically as it is being developed and deployed.
We all have used IAM credentials to access our S3 buckets. But it’s not a very safe or recommended practice to keep our Access keys and Secrets stored in a server or hard code them in our codebase. Even if we have to use keys, we must have some mechanism in place to rotate the keys very frequently (eg: using Hashicorp Vault). Another widely adopted method is to use IAM roles attached on the EC2 instance or the AWS service accessing the bucket.
But, what if we need access to the bucket from an on-premise Data Center where we can not attach an IAM role?
Yes, we can obviously use IAM credentials and secret tokens with the rotating mechanism. But setting up the key rotation mechanism itself could be another overhead if we do not have one already in place. What if we do not require keys or roles without making the bucket public?
In this blog, I will make an attempt to cater to this problem with another alternate and easy solution.
Nowadays, it is very common to run applications on Spot instances. In this scenario, where a spot instance could be terminated at any point of time because of AWS pulling back their resource or ASG Scale-In incident, we need to have something in place to handle the termination smoothly so that we can complete our final tasks before the system shutdown. It could be executing some scripts, unmounting some storage device, shipping final log files to S3, or uploading cache data in a centralized server like Redis. Today, I will attempt to cater to this problem.
First of all, let’s think of trying to run a custom script prior to shutdown in our local system. If everything works fine, the same would be applicable for ec2 spot instances too.
But Why Json ?
We generally think JSON means data provided general output from any API. But, if we talk about any technology, JSON is a very common programming language or we can say format, which is used as the output format of any resource. While using DevOps tools like Docker, Ansible, or any other tool, we generally get the output in JSON format when we use any output command like Docker inspect or Ansible facts gather.
During this lockdown period, people are usually working from home which means they all are contributing to work by staying at home. So, if someone wants to work on something online, such as on a particular private or public server of a company, depending on the scenario, will need a network route to that server.
Meaning, they first need access to that particular server either via a public network or using VPN. These things have their own set of complexities. Therefore, we will discuss a few aspects of network access & their drawbacks: