Are you responsible for the security of application containers running in the cloud?
If so, you’ve found the right source to help you secure it. In this series of securing developed applications hosted in the cloud. We’ll walk through where the code starts and follow it along the journey from development environments, to code repositories, to containers, to orchestration, all the way to the cloud platform. We’ll review and recommend security controls every step of the way.
Your specific implementation may vary a little, but there’s sure to be many applicable controls you can leverage to reduce the security risks of containerization and orchestration in the cloud.
The scope for this multi-step undertaking is:
- Secure the application against threats to integrity, availability, and confidentiality.
- Secure it in a what that is non-developer language-specific.
- Secure the application being hosted in Docker containers.
- Secure the orchestration of the application done by Kuberentes.
- Secure the application in the cloud being hosted on the Google Cloud Platform.
Follow along as we attempt to successfully secure this GitHub, Docker, Kubernets, and Google Cloud Platform application implementation.
Foundation
“A journey of a thousand miles starts with a single step.” – Chineses proverb.
When running container applications hosting sensitive or confidential information the journey should begin where the data is born. In this situation, we’re trying to secure data within a Kubernetes environment. So we need to start with where the application is being built.
We will fast forward through the first few steps and assume this is being done without a detailed explanation:
1. Create a company culture where security is important.
2. Create solid and straightforward information security policies.
3. Create supporting data handling guides, and resources.
4. Host user security awareness training for all employees.
5. Create specific user security awareness training for special groups that have high risk. (Application developers in this case).
6. Qualify to hire talent based on a standard questionnaire process.
So at this point, you have a company that supports information security, they believe it’s important. They’ve all been trained. You’ve hired some really good developers that know their stuff and understand the basics of security and can help protect against the most prevalent exploits like SQL injection. Have they heard of OWASP? Good, then let’s get started.
Developer Security Group
Create a group of employees that are considered ‘developers‘. Depending on the size and scope of your company you might have to break this down further into subgroups like; application, database, SaaS, CRM, ERP, Web and so forth.
The goal here is to manage your developer ID’s in such a way that a single change will produce all the security results and impacts needed. You want the ability to remove an ID from one single security group and have all the access removed, instead of individually managing a single user ID’s within development systems and applications.
Developer Environment
Work with technology leadership early and often to learn what development initiatives are being planned for the next year, and ideally as far out as you can. Your goal is to learn specifically what application are on the dock for development, where they will be hosted (internally or externally), what data the applications will host and deliver, and what programming languages will be used to achieve this.
Using this information you can agree on which of those applications will be considered a ‘HIGH‘ risk. You can agree on what hosting platforms will be used. You can also review and agreed what the standard environment for development looks like. For some, this is a virtual box running on their workstation. For others, this is a full-blown set of servers and databases for the specific scope of development. Learn what employees will be developing with what development tool-kets and environments, wheater it is Android Developer Kit (SDK), or .NET Studio, or Java (JDK), so you can know where to expect these development kits installed and running.
Secondary Accounts
Next, create secondary ‘development‘ ID”s for all the developers. Include them in the correct security groups, and provision those security groups to the appropriate resources (virtual workstations, or development servers).
I recommend creating a naming standard for development ID’s, such as adding a ‘D-‘ at the beginning of the name. It makes it much easier to search and review for developer accounts, review access, and create whitelists if you’re leveraging a SIEM with a security correlation engine. It also makes it easier on the eyes to identify non-developer accounts with developer access and privileges. Which brings me to my next point…
Remove the user’s primary accounts from the development resources. This prevents an attacker pivoting from a phishing exploit to quickly owning all the application code. Keep the two roles separate. This will pay security dividends.
Remove Local Admin
Remove, or never allowed, local administrative rights of the developers to their workstations. Only provision administrative access to the development resources. I know, it’s hard. It’s a culture change. But our culture has adapted to many changes, and this is an important one. The only administrative access the developers should have is to the development environment. This does not include the production environment.
Service Accounts
Build a policy for ‘service accounts‘. Be clear stating that in production they cannot be logged in interactively and are only reserved for services. Service accounts cannot be used by employees for the management of resources. If service accounts need to be logged into for troubleshooting and support, a ticket needs to created (or whatever your support process is). The credentials will need to be updated when the support is over, and the interactive login ability removed via policy.
Concerns
A common argument is that developers need administrative access to production boxes to support them. If the application is tested through a proper development life-cycle, there should be a low risk of production issues.
Create a break-the-glass security process for when there is a production issue that developers need access to. Add this credential to your SIEM engine for alerts when it’s used. Ensure that when the account activity is alerted on there is a production incident in progress. Test this process beforehand to ensure it works.
The same can be said for service account access. The only situation I’ve seen that I have not been able to successfully remediate and prepare for is database administrators having administrative access to production. But this article is focused on the application development, not database administration (so I can skate out of that discussion for now.)
You can also store the service account credentials in a break-the-glass procedure if you feel it necessary for production support.
Conclusion
That covers the fundamentals of starting off with a secure development life-cycle. With these core security tenants in place, we can move forward in our security journey to protect our application in GitHub before it moves to Docker, and Kubernetes in the cloud.
In the next part of this series, we’ll focus on development languages and libraries. How can you review and ensure the security of what the developers want to use to build what they need to deliver?
Recent Comments