In recent years, DevOps has embraced automation in this new cloud-native world. Infrastructure-as-code (IaC) is now commonly applied to spin up servers, automate configurations, set up storage and apply standard networking features across services. Using new tools and abilities to streamline operations across the application life cycle, development teams have significantly improved their deployment agility.
But, in this new paradigm, who is responsible for security? More tools promote a shift-left approach and full-cycle ownership for developers. Yet, application developers already have so much on their plate. Plus, they don’t have a full window into fine-grained vulnerabilities, exploits and the many new compliance requirements arising on a daily basis. On the other side, IT security engineers don’t often understand the intricacies of the expanding DevOps tooling continuum. Without better collaboration, powerful cloud-native commands could get out of hand, requiring remediation.
I recently chatted with Om Vyas, co-founder and CPO at oak9, to get his perspective on how teams should confront security for cloud-native deployment. According to Vyas, security requires the same automation that DevOps has embraced for IaC. But instilling this mode will require cultural change, collaboration, and visibility into the implications of increasing development velocities.
Problems With IaC in Cloud-Native
Just ten years ago, software was delivered much differently, Vyas says. Departments were siloed, and IT and operations controlled hardware on-premises. This enabled engineers to lock everything down with firewalls to control runtime environments. Operations tended to move more slowly, but folks had more direct control over access, networking policies, data flow and communication boundaries, he says.
Fast-forward to today’s cloud-native architecture, and engineers have tremendous power at their fingertips. A developer can instantly launch cloud services like an EC2 instance using Terraform, programmatically manage clusters on Kubernetes, invoke serverless functions and many other abilities. However, operators may not always readily understand the repercussions of such velocity. When introducing new features, what are the security implementations if infrastructure automation is changing the existing architecture?
Vyas explains that the constant velocity and delivery of new features causes a disconnect when addressing security. “DevOps is a three-legged stool,” says Vyas, made up of development, DevOps (or SREs) and security. When developers are moving at lightning speed, security and SREs lag behind without automation capabilities. Exacerbating the issue is that many engineers will simply copy and paste pre-written IaC commands. These configurations are often generic, considering networking and storage but not taking security and compliance into consideration, Vyas adds.
General Methods for Securing IaC
AWS, Azure and GCP made it very easy to spin up storage, compute and networking resources. But not considering the security implications of IaC could come back to haunt development teams. For example, confusing the nuances between elastic load balancers could potentially expose sensitive data. Of course, some organizations are building proper IaC abstractions and modules. To do this, “you have to look at the whole picture,” Vyas says. More specifically, this will require cultural change, increased visibility and full-cycle development.
Like with most IT changes, improving security necessitates a cultural shift first. “Technology is secondary,” says Vyas. Embracing cultural change entails increasing collaboration among programmers, DevOps, SREs and security professionals to decide on areas of autonomy. “Really coming to the table to agree on the cultural shift is the hardest part,” says Vyas.
Culture change could encompass realigning the deployment processes or deciding when to involve security teams in new feature releases. It could also include standardizing on new code analysis tooling and workflows. One way to sell a security-first mindset is to reiterate the benefits of solving problems the first time instead of making rewrites down the road, Vyas adds. Regardless of the specific tactics, cultural change must be a shared mission.
Next up is having excellent visibility. If changes fundamentally alter the architecture of an application, Vyas explains, teams need to know what areas of security have been affected. A tricky part is adding more security checkpoints without straining the developer workflow. The secret sauce here is to automate; automate everything, says Vyas.
Developers continue to take on extended life cycle responsibilities around a codebase; some call this trend full-cycle development. “Whether we like it or not, that’s where things are heading,” says Vyas. Providing autonomy to developers over the application life cycle does offer productivity benefits, Vyas concedes. It could reduce the need for external approvals and enable quicker software changes.
However, this autonomy does not mean others aren’t involved with the security process. The onus of security shouldn’t just lie on the developers and SRE teams, says Vyas. He reiterates that security is a shared responsibility throughout the organization. “How else can we ensure that all changes are continuing to have visibility, and help build security in as an app is changing, month over month?”
Future of Security and IaC
For new features that change the underlying architecture, teams need visibility into the potential security implications and risk factors ahead of time. For example, when adding an analytics dashboard, how do you know the serverless function has the right level of access to the database? “Is it exposed publicly? Is it encrypted at rest? Does it have a proper key management system? How do we ensure every change isn’t creating additional risk?” asks Vyas.
Increasing security awareness around these factors isn’t something that can be halfhearted or sloppy. Similar to DevOps as a general practice, the big gains of adopting a security mindset come in the last mile. Furthermore, with rising multi-cloud adoption, companies will require their own security ethos if they are to apply consistent cloud-agnostic protection across all software divisions.
Looking to the future of cloud-native security, Vyas foresees continued investment into methods to automate security around automated infrastructure changes. (That’s a lot of automation!) Eventually, with continued intelligence around such automation, he predicts we may soon move from IaC toward more low-code/no-code capabilities, often referred to as ClickOps.