Cloud – DEVOPS DONE RIGHT

Checkov a Must Tool for Infra CI

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.

Know How to Access S3 Bucket without IAM Roles and Use Cases

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.

Learn the Hacks for Running Custom Scripts at Spot Termination

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.