What is container security?
Container security isn’t new and there are a lot of vendors out there today pushing different variations of the same product. Picking a tool is the easy part but actually implementing standards with a design is easier said than done. This post covers some of the basics you can run through to help build your own plan on how you are going to secure containers within your environment.
A lot of this may not require additional tools but instead understanding and awareness.
Are you running any containers today?
This should be your first question, and if the answer is no, are you sure? Remember, that developers can spin up containers on their workstations, servers, or cloud platforms. Having visibility is a big problem and one often fixed by “tools”. This is something I agree with, as you need something that can give you continuous visibility of your estate. Cloud providers do give you oversight, but it may not be enough.
If you have a small presence, you may not need to purchase one, but instead, build one.
For example, if you have an Azure subscription, you could build a script to highlight container repos and AKS clusters:
This would be free, and would just use the Az Powershell module. It wouldn’t give you a great deal of insight, but you could monitor what is there and apply automation. If you don’t care about automation, then simply use the portal.
Regardless of the method you chose, you will still need to answer the following questions before making a final decision. Here are a few to get you started:
- Do you know where all your containers are today?
- If a developer span up a docker instance, or Kubernetes within your environment, would you know?
- If a container was compromised, would you know?
- If the image/code being used contained malware or credentials, would you know?
- If a container was attacked, are you capable of responding?
- If the host of the containers was compromised, would you know?
- If the container had vulnerabilities, would you know?
Once you answer questions such as these, you can start to highlight gaps. To fill these gaps, you may need education, people, or tools.
The education part is a biggie, as containers and Kubernetes are hard to grasp. Although they seem straightforward to some, for most, the aim is to know enough. In Security, that’s all we can do really. If you don’t specialize in it, you just need to know enough to be able to join in the conversation.
Hint: If you’re on Twitter, @IanColdwater is a great follow.
Let’s make it simple
When talking about container security, it’s easier to break it into two sections: Pre-runtime and runtime.
- Pre-runtime — Everything before it’s actually running.
- Runtime — The container is running live and can be accessed.
Pre-Runtime Security
The aim here is to have visibility into the images/code being used as part of the CI/CD lifecycle and to check if it’s secure.
For this part, you will need to find out where your images are being hosted, and what images you are using. If this is for IaC, then think about where is the templates/code hosted and who develops them.
The idea here is to see if we are running trusted images/code. Are your developers checking to see if they are authenticated or trusted, or just downloading whatever? If they say “trusted”, ask them from where and if always.
Drifting is a problem within DevOps, as it means the developers have moved away from the approved images/code. This then creates a drift that could lead to vulnerable or unsecure code being deployed. This is where you may want a “tool”.
There are plenty of code scanning or image scanning solutions out there to help notify you of any:
- Visibility of what is being stored (Inventory).
- Vulnerabilities.
- Secrets exposed (Hard-coded credentials / keys).
- Misconfigurations.
- Weaknesses.
This is a key stage, as pushing unsecure code/images is never a good idea. If you don’t secure at this stage, you put all the pressure on the runtime stage. This can cause admin overhead as they would have to backtrack after deployment. It’s better to spot/stop at this stage, so that you can “modify” any images found to be vulnerable.
A lot of code scanning solutions have criteria settings as well. This is something you defiantly need to consider as you want to set a “blocker” during the pipeline so no images/code are deployed that doesn’t meet your standards. If the code/images don’t meet these standards, the pipeline needs to fail and highlight to the developer; WHY.
Hint: Pick a tool that makes it clear else the develops may just ignore, complain or turn it off.
Runtime Security
This should be like bread and butter to Security ops. Here you are securing the actual end product.
The first step is the host. If you are not running a cloud service, you may be running docker on a Linux host. If this is the case, then secure the host with extra considerations. This is not just another Server but a “hosting solution”.
- Limit the network access inbound and outbound.
- Install your Security stack (Agents).
- Monitoring and heavily auditing changes.
- Feed any logs into monitoring and SIEM solutions.
- Limit root/admin access as well as SSH/RDP.
- Review if hardening standards need to be applied.
- Remove any tools, software or features that are not required (Attack vectors).
These again may be easier said than done, but it’s worth it. If this box is compromised, it can filter down.
The networking aspect may also need greater consideration, especially with inbound/outbound access with regards to the internet. Containers are “images”, so they can have networking configured. Try to limit each container on the firewall so that no lateral movement or internet exposure spreads.
Now, onto the containers themselves.
Again, remember that these are actually images. Although they come across as “just the applications”, they are not. For example, when people say, I just run an Apache container, they are but can still be accessed like a host:
You can also run containers that are just Linux distros:
The big headache for Security and containers is how easy they are to deploy. If you don’t know what they are deploying and from where you’re always on the backfoot to respond.
If you can get a tool that sits alongside these containers, then you may be able to get ahead. This is what I’m seeing from multiple vendors. Solutions that sit alongside your containers to allow continuous monitoring and security as the develops scale. If a developer adds a bad image that passes the pre-runtime security, you really don’t want to rely on agent deployment. Not having to rely on someone installing an agent is bliss. You need something that is there on day one and doesn’t need a repeated process. Many vendors offer this, but they need to match your wants and cost.
If you are having to deploy an agent to each “image”, remember that it’s prone to mistakes. Some of the products nowadays are agentless, but the trade-off is often cost. Finding the balance is key.
Look for solutions that include vulnerability and drift detection as well. Remember, although we are scanning the pre-runtime images/code, things can change. If you are past this stage, you heavily rely on your runtime design. Having continuous scanning will help spot vulnerabilities, drifts, and weaknesses. If these are spotted, you can regroup and run through the CI/CD process again.
If it’s not an image issue, but more configuration such as running with high privilege you may be able to remediate it without running through the whole cycle. The whole DevOps piece is a continuous flow, so it shouldn’t necessarily be a bad thing if you do.
It also might push for certain containers to be turned off if flagged as a risk. Remember, turning it off is always an option.
If you can’t fund or find a solution that helps protect the containers directly, then go back to basics. Securing those “containers” or “images” can be done without tools and applying additional layers may not come at additional costs. The basics will often protect against the majority, so they are worth doing:
- Limit access for accounts.
- Limit private network access (Lateral Movement).
- Limit external network access (Internet & inbound).
- Remove any unnecessary tools, and software that can be abused.
- Enable monitoring and auditing.
- Update and patch (OS and application).
- Monitor the vendor and application for CVE and Zero-day news.
- Apply encryption.
- Back up and secure those backups.
Hopefully, this gives you something to think about. Remember, many vendors will break out “sections” of the lifecycle so it’s important to be aware of each stage. Container security isn’t just at the runtime. It will be a continuous process to ensure protection from start to finish, with the need to gain visibility through automation.
What I haven’t discussed here is the environment layer. Whilst these apply to the lifecycle, the policy will need to be enforced/monitored in the environment. This is to ensure you control the deployment aspect or at least limit what can be created and how. This is something I may cover in my next piece.
If you enjoyed reading my content and want to support, why not consider signing up and becoming a member. It’s $5 a month, for unlimited access to all stories on Medium. Join now! 🙂
Need help? Why not also check out my Fiverr or UpWork.
Regardless, thank you for reading!
amoran.io 
Leave a Reply