With the ever-growing number of resources deployed to your cloud infrastructure, ever-growing services rolled out, and an ever-growing number of users, bots, CICD (Continuous Integration & Continuous Delivery) pipelines interacting with a cloud environment, how does one stay on top of what is happening right now?
There has been an increase in critical events in cloud infrastructure. Critical events will easily slip through the cracks and be lost in oblivion if someone or some system does not respond to the event.
Once an event is captured and some visibility is gained, what are the actions that should be taken? When should it be acted upon? In which conditions? And most of all, can any of that be automated?
For instance, if an event is about a resource creation that is non-compliant, the owner should be notified of such an event to correct it as soon as possible. The owner will then take some action to fix the problem or add an exception to the compliance scheme. At the same time, someone else will have visibility when this event is sent.
In any case, this kind of action should be automated. Engineering time is more valuable than chasing the right person or fixing something that is broken.
What If a solution existed that solved all of this? That is the aim of Cloud Responder, a simple open-source cloud detection and response tool.
With an easy setup, it deploys the resources necessary to make it work and will instantly start listening to noteworthy events the tool is configured to capture.
Once these events are captured, a series of actions can be triggered, one after another, or in parallel to ensure some level of response is provided.
Use Case 1
For instance, let’s imagine a user has just created an S3 bucket on an AWS (Amazon Web Service) account that does not comply with the naming convention. The tool will capture the event and will trigger a series of actions to respond to it. Recipients should receive an email to notify them of such an event. Also, a Slack message should be sent to notify the security team that a new user has been created.
Then, a one-hour window will be given to allow team members to remove or rename the resource. Once the hour is up, the tool will check if the resource is still present. It will then automatically remove the resource if it is still non-compliant, send an email, and a Slack message.
Use Case 2
Now, let’s imagine another example where you want to be alerted by SMS whenever someone is logging into your AWS accounts on weekends. With Cloud Responder, you can create a rule to capture login events and trigger a series of actions for this timeframe. Once captured, an SMS notification goes to the number of your choice. You can create an infinite number of rules and actions for these rules with YAML files.
Staying on top
With such a tool, it is easy to stay on top of what is happening in your infrastructure, by either using off-the-shelf rules and actions or creating custom ones. Also, setting up the tool and letting the automation take control will cut downtime on these annoying but critical tasks.
Any cloud practitioner can have visibility with the Cloud Responder project. Whether security-minded, reliability-minded, or just willing to know what is happening. The tool can capture and treat the events that matter most so the practitioner can focus on their best-added value.
Since this is an open-source project, anyone can easily contribute to add rules or actions. There may be bugs and issues that can be tracked directly into the GitHub repository’s Issues section.
The infancy of the project is a great time to give feedback. This is also a great place to request early access to the project and book some time for a walk-through. This will help improve the project and help us define what to work on next.
There are already some interesting features on the roadmap. For example, multi-cloud support (AWS, GCP, Azure), increased modularity to allow anyone to develop rules and actions from their own GitHub repository. In addition, an architecture improvement to enable plugin creation.
The tool could also deal with events that are SaaS-related, such as a user having admin privileges in Atlassian, or when a new user has been created on Slack.
Interested in giving it a try? Ask for early access in the comments below. Once added to the GitHub private repo, you can then install the project locally. You will be able to deploy it to your AWS account in minutes. It does not create too many resources, and the entire project can be quickly uninstalled.
We hope you will like the tool and you will find a use for it. I look forward to hearing your thoughts about this and answering your questions in the discussion forum.