All right, so this time we talk about cloud automation and other cloud threats. The words cloud and automation are a match made for life. The flexibility and the elasticity of the cloud environment would not be so spectacular by far if we wouldn't be able to leverage that flexibility without manual intervention. That's why cloud environments are very friendly with programmatic approaches to resource management and creation. and to automation and orchestration tools designed especially for infrastructure or configuration management.
So this is possible because most likely any cloud provider that you choose will allow you to interact with it, not only through a web console where you just click your way through, but also through a REST API endpoint. So let's see what we can use to talk to those REST API endpoints. Now the first and the most basic method of automating anything is scripting. We're talking here about Bash scripts, Python scripts, PowerShell scripts, Go, Ruby, doesn't matter what type of script you have.
There's a saying I like, if it's worth doing once, it's worth automating. And yes, the simplest form of any automation is a script. Scripts are most of the time used as a collection of tasks, administrative commands that can be run without human intervention. Now, for a cloud environment, scripts can be leveraged to automatically create resources. configure resources or users and permissions and so on.
But at its core, a script is still just a collection of manual tasks. The commands in a script are similar to the commands that an admin would potentially input manually directly into the system. Now, of course, they probably follow some best practices and make some checks and are carefully written, but mistakes can happen.
And they do happen. Either typos or simply forgetting about some specific configuration parameter. These small errors can lead in time to large problems when managing complex infrastructure. So at some point, your, let's say, cloud servers might even reach a state where your scripts don't work any longer because their configuration has changed over time or their software packages have been updated and your scripts have become obsolete, they're behind.
And when a script fails to work, the only thing you can do is go in there and try to manually fix things and there goes your automation. out the window before it even happened. So we're going to need something better, and we call that something better, orchestration. Now, automation in general is focused on making simple tasks easily repeatable. Now, orchestration goes one level higher and deals with automating and building the sequence of tasks to be executed.
For example, orchestration might mean an entire process that starts with the creation of a virtual machine, the installation of the necessary web services on it the configuration of those services the creation of the i don't know the clouds networking where the vm resides or adding that subnet to a load balancer and perhaps even running some tests to check the health of the instance and see if the traffic flows properly now each of these tasks can be an example of automation in itself so each task can be executed by a script but that's why orchestration is sometimes called automation of automation and orchestration is actually a lot more than just sorting some scripts and executing them one by one of course otherwise it's still scripting many orchestration tools have really advanced features such as implicit validation most tools have very strict requirements about all the parameters that need to be present in the automation workflow in order to be deployed now this helps tremendously with avoiding errors mistakes and typos because this software checks whether all the parameters and and all the valid parameters are in there and they have been entered correctly. Also orchestration tools can take resource dependencies into account so that resources are deployed in the actual order allowed, not just by the cloud environment, but the order that makes sense for us and for our infrastructure, perhaps for our applications, and make sure that everything is started according to the requirements of the business process behind it. They also add sometimes state knowledge. This one allows the orchestration tool to decide whether some or all the steps in the orchestration workflow need to be executed or not, depending on the current state of the infrastructure.
So it basically allows the tool to know the state of the infrastructure before deciding what, if anything, needs to be done. And finally, the last one, idempotency, also related to state knowledge. means that applying a workflow multiple times over the same set of resources, over the same piece of infrastructure, should help you.
have no effect no changes on any subsequent applies this also means that you can reapply the same workflow to validate that it's still compliant to your desired state so you apply it once it deploys the infrastructure if you try to apply it again it's going to tell you due to its state knowledge this infrastructure is already deployed i don't need to do anything else right if no changes need to be done then you can consider your infrastructure compliant And well, the amount of tools out there that deal with automation and orchestration is absolutely huge. So just to give you a taste here, I'm going to mention Terraform. It's a tool for infrastructure as code. We're going to talk more about infrastructure as code later on.
Terraform is designed to deploy and manage resources in public clouds, such as AWS, Google, Oracle, Microsoft, and so on, using simple configuration files that describe resources in code. And then Terraform reads those files and deploys the resources in their corresponding cloud environments. Another one is Ansible. This one is designed for configuration management specifically. So it can create resources, but we mostly use it to configure those resources, to connect to those virtual instances, and then start updating operating system settings, creating users, setting permissions, installing packages, updates, downloading additional information, and so on.
Ansible is great because it doesn't require any kind of agents installed on those servers, but instead connects over traditional protocols such as SSH and runs configuration scripts written in YAML, right, known as Playbooks. Now on the same configuration management area, we're going to find Chef and Puppet. Chef is also designed for configuration management and uses scripts called Cookbooks written in Ruby.
It's going to require a small agent to be pre-installed on the instance that is supposed to be managed by Chef. Puppet, again, is similar to Chef, also relies on an agent-server architecture. We're going to mention here Docker, right?
Designed for developing, shipping, and running applications in containers, also includes some limited orchestration abilities, such as Docker Compose or Docker Stack. But the master of container orchestration is Kubernetes. This one fills that limited orchestration gap, which we can find in Docker, and introduces an entire new abstraction for managing container-based applications and the infrastructure behind it, like storage, networking, and external access, with a huge amount of flexibility. A more recent technology, which emerged kind of at the same time as the modern microservices approach, It's called function as a service, also known as serverless computing or serverless architecture.
So what exactly is this? Is running code without servers, without infrastructure? Well, it is kind of advertised like that, as in any function as a service offering, and all cloud providers have it. They advertise it as not requiring any kind of infrastructure.
But as we all know, code cannot just run magically. So it. it does need some infrastructure to run on.
It's just that you're not gonna gain access. You don't have any kind of visibility onto the infrastructure that your code runs on. So you don't have to manage the servers. You don't have to manage the storage.
You don't have to manage any operating system. You actually don't even know what those are behind that code. This is all managed by the cloud environment. It's basically a kind of a simplified, dumbed down version of platform as a service where the cloud provider offers you the infrastructure and you just bring your own application you bring your code that needs to be executed so all you need to do is to provide a code for a function we call it function because we're mostly referring it from a microservices perspective of running a specific piece of code that does a simple atomic thing like you know processing an image or processing some kind of input right so that's why you call it a function it doesn't really have to be an actual function in machine code But we do just provide that code, which is actually a microservice, and that function is going to interact with other similar microservices in order to provide some results to client requests.
Now, the cloud takes care to always have the function up and running and available. You just pay for how much you use, and you never have to worry about the infrastructure behind it. So you only pay for how long the code that you're providing runs.
Now, that code actually runs in most cloud providers in some short-lived containers. So when the function needs to be fired, when the code needs to be launched, there's basically a small container that gets launched behind the scenes, which runs your code. And when it's done executing that code, it destroys the container, kills all context, and reverts back to its initial state. And also, you don't pay for that code. anymore.
If you want to learn more about how this function as a service is used in real life, here's a nice case study about how Netflix uses it from within AWS. And of course, we still have to talk about security. Now, security for serverless computing is some sort of a topic in development, but mostly it's going to be cloud dependent. Now, your responsibility is to secure cloud access to that function as a service service.
Make sure that the clients that access those cloud functions don't get compromised. Also, from a security perspective, if you don't have to worry about the infrastructure and its availability, that doesn't mean that things cannot go wrong in the provider's cloud as well. You might not have much visibility on the disaster recovery options available in your provider's cloud. And most likely, there's nothing you can do if a disaster happens because you have no visibility onto the backend infrastructure. So remember that function as a service doesn't run on magic, but still physical servers that can fail.
Now let's cover a couple of the most common security issues or threats that tend to happen when you're using a cloud environment. And APIs, first of all, regarding any API that you might be using, for example, the API of the cloud service provider itself is a security concern in itself. So you can either use the API of the cloud provider or you might have an API exposed in your own applications running. in the provider's cloud.
And some basic principles that apply here. First of all, make sure to secure communication to that API endpoint. It must be HTTPS, at least when you're communicating over the internet. Now, don't just enable HTTPS, make sure you don't allow HTTP connections, and you'll return an error if somebody attempts to access that endpoint over pure HTTP. Of course, whatever you submit in an API must be properly validated because that's input.
just like any other kind of input. Don't allow things like injection attacks or buffer overflows by failing to sanitize your input. Now, APIs can be attacked through a denial of service attack.
Don't forget to enable things like rate limiting for any incoming requests so that a denial of service doesn't happen. Don't allow more than X requests per second or per minute. Make sure you choose that X so that it matches the expected normal usage of your application, of course. Also careful with in-house developed APIs. Programmers might attempt to follow best practices, but details are often forgotten.
That might expose your application in unintended ways or lead to some sensitive information disclosures. So make sure that the API doesn't give to anyone access to any resource. Make sure you. thoroughly validate any kind of resource request another important area of concern is improper key management now for an api to accept your requests you will need to present a key an api key now those keys in many apis are statically generated you create a key in the cloud portal and you copy it to the client's host and any requests that you generate and you send to the cloud endpoint have to include that key and of course they should be protected using tls I don't need to tell you this at this point.
Still, this doesn't protect against some, let's say, third party stealing or obtaining that key using any means necessary. A compromise key can mean that an attacker can perform all the actions allowed by that specific key. It might include even destroying your cloud infrastructure or making any kind of changes in there.
So as a best practice, avoid hard coding API keys in your applications and your scripts or in any source code. either store it in a different location on your machine or even not on the disk many api utilities accept environment variables for key storage so that sensitive information such as api keys never reach the disk they're never persisted on the disk don't forget to apply the principle of least privilege like in any security area make sure that you create specific privileges for each type of key according to its Valid usage scenarios. Don't just create a super admin, one key to rule them all and give it to everyone.
Careful with unused keys. They are sometimes forgotten. Make sure you delete them to deactivate them. If they're unused, chances are that nobody's monitoring them.
And if somebody gets their hands on an unused key, well, nobody's going to know that somebody else has access to the cloud environment. Now, don't forget to change those keys periodically, which is called key rotation. That's just deleting and recreating a new key, just in case some keys have been compromised when you weren't looking.
Don't forget to store those keys securely. There are many solutions out there dedicated to encrypting credential stores, such as Vault from HashiCorp, the same company that makes Terraform, and it's free, so why wouldn't you use it? And lastly, don't ignore the security posture of the machine or the computer, the laptop that you're using to interact with those APIs.
You can whitelist some workstations to run only a limited number of applications or to access some very specific communications channel so that you minimize your attack surface and you avoid the unfortunate compromise of the machines that you're using to manage your cloud environment. And storage. Of course, unprotected storage is a big issue.
Cloud storage has many shapes, many colors, many types of services. But regardless of the type of storage that your applications or your users are using, you will have to manage some sort of an access control policy on those cloud storage entities. Who has access to which type of data?
So permissions on cloud storage can be a combination of access list, IP access list. cloud users, machine accounts, regional ACLs, and so on. They can become quite complex and some admins will take the shortcut of either leaving the default settings or some very permissive settings so that they won't have to dig deeper into the details of access control. This can have two unfortunate consequences.
First one is allowing write permissions to the public when they should only be read-only. Or allowing read permissions to the public when they should not have access at all if it's about confidential data. This is one of the most common reasons behind data breaches due to errors and misconfigurations, not actual attacks.
Like this example of top 10 worst S3 bucket breaches. A bucket is in a container for an object storage service in Amazon Web Services. Now, misconfiguring policies, access policies to those buckets... are the number one source of data breaches all over the world. So often enough, AWS customers are exposing themselves unintentionally, of course.
And don't forget that insider threats are still a concern in cloud as well. So be aware that account compromise can happen. Information can be intentionally leaked. And when it comes to cloud storage, object storage, it's actually not even that difficult.
Here's one example in my AWS account. and we have one bucket configured right here and if i click on it and i go to the permission section i can see that by default my access is public any objects in here can be public i just need to click edit here on the block public access section and i can either choose to implement some sort of an acl here or i can just simply block all public access to this bucket and click done click confirm here just to prove that i know what i'm doing And that's it. I mean, come on, people. It's not that difficult. And don't forget about logging and monitoring in the cloud as well, because generally you will have a harder time here, a bit less visibility on the cloud compared to what you can see and access on-premises, which means that performance management is either a bit more difficult or completely out of your control.
And also incidents can go undetected for much longer in the cloud. Now on the other hand, the good news is that all cloud environments have dedicated solutions for monitoring and logging which is tightly integrated into all their services. So most of the time it's going to be just a check mark to enable a collection of logs from a specific service or from one of your instances. A good API also should provide enough monitoring capabilities as well including alerts when a denial of service is happening, for example.
and since we still have our bucket open right here under the properties section if you scroll down here in aws we can enable server access logging that is logging requests for access to your bucket just click edit here and it's just a matter of clicking disable or enable all right so that's logging here now under the metrics section there's monitoring right these are the bucket metrics here how much space am i using in the bucket how many objects i have how many requests i had And I can send all this in CloudWatch, right? A dedicated solution for metrics management and reporting. Then again, not that difficult, but you are limited to only those metrics that the cloud provider allows you to see and to monitor.
Right, so that's the end of our second discussion about the cloud. For the exam, make sure you remember the methods by which you can implement cloud automation, starting from scripting all the way up to orchestration. Be able to describe.
function as a service or serverless computing and also make sure you can enumerate and explain some of the most common threats that you're facing when you're moving your infrastructure or your data in a cloud environment all right so thank you so much for watching if you found this useful like and subscribe and see you next time when we will be talking about vdi that's virtual desktop infrastructure containers and microservices see you next time