Hjem Blogginnlegg Practical security at the nexus of Kubernetes, Devops and Cloud
Blogginnlegg
Blogg

Practical security at the nexus of Kubernetes, Devops and Cloud

Practical Security at the Center of Kubernetes, DevOps and Cloud

A not so untypical Kubernetes solution

Many of our clients are building solutions in the cloud based on Kubernetes. They have a modern software development methodology, so agile practices are a given to them, and if they haven’t already done so, they’re trying to implement DevOps. But each of these three concepts –Kubernetes containers, cloud and DevOps– are competence intensive disciplines, with a considerable flux. They require constant attention and effort to stay on top of the latest updates.

And then you have security. Security by itself is a rapidly evolving field, also requiring constant attention. But trying to secure something that is built on rapidly changing technology is quite a challenge. It’s therefore no surprise that many of our clients struggle to cope with all the new vulnerabilities being discovered every day, and updates and changes to the security mechanisms and best practices to secure their solutions.

One possible strategy to handle all these challenges is to enforce compliance with a standard, a set of principles, or maybe a list of requirements that the company has set up. Alternatively, or in addition, one might do security assessments, perhaps even on a regular basis, either internally or by an external partner.

For a software development team, the results of such assessments often only add to the headache. The team now has a list of known vulnerabilities and non-compliances. Usually, the list is long and in many cases of the check-list variety. But where should the team start? Even if you just look at a single item, what would be sufficient effort to be able to cross it off the list? Which of these items need to be checked off, and which can left on the list as an issue you can live with? And are you out of the woods by the time you’re done with the list? Often not. New features have been added. The supply chain has changed. You need to decide when to start again. As the exercise takes effort away from other things — like creating functionality — the team has a built-in incentive to do security reviews or assessments seldom and with minimal effort.

There is a better way to go about this.

At Computas, when we work with project cybersecurity or advise software teams, we strive to make the list short and prioritized. And even more important: list items are not of the check-list variety; we provide recipes for what to do more than stating a goal without saying how to get there or how much effort is sufficient.

Our practice framework, which we’ve termed “6C”, is inspired by Kubernetes “4C” of Cloud Native Security, and includes the following:

  • it’s an evolving, operational framework,
  • it focuses on the nexus cloud, DevOps and container, and has peripheral focus on topics that relate to these three core areas,
  • it stems from practical work with security in software development.
  • it may fit into various security management and risk framework standards as operational capacity.
How the “6C” cybersecurity framework relates to other security topics. Green is core focus, yellow is peripheral, and red not a focus.

Given a focus on subject-matter, cf. the figure above, we typically do a broad, brief survey of the different “C”s when assisting a project:

  • Core: These are foundational security issues where we work through project setup, ownership, organization, networks, monitoring, culture, competence, prevention vs. containment, disaster management, how the project handles risk and incidents, separation of duty, identity and roles. This C’s slogan is “Know what you’re doing. Own up.”
  • Chain: This is where we focus on process security: pipelines, doing things over and over, automation, and toil. Frequent review topics are software delivery pipeline, supply chain (3rd party dependencies), infrastructure-as-code, testing, operations/DevOps, the risk+incidents+backlog nexus and sustained quality. This C’s slogan is “Do it all, every time. Sleep well.”
  • Cluster: Here we work with security on nodes, network and VMs. Frequent topics are cluster hardening, API access, image management, zero-trust, defence-in-depth, mesh, secrets, logging, monitoring, isolation, attack surface and service account/access token management. This C’s slogan is “Secure the VMs.”
  • Container: This is often about Dockerfiles, dependencies, images, repositories, hardening and privileges. This C’s slogan is “Secure the images.”
  • Code: This is about the internals of the business application itself. Focus areas are API vulnerabilities, resilience, confidentiality and information integrity, application logic, clients, authentication and authorization. This C’s slogan is “Secure the application.”
  • Components: Here we work through security aspects for important run- and build-time components in the architecture. These are typically managed cloud components like databases, API management, Pub/Sub, firewalls, builders and SaaS services that the solution depends on. Since this is about components, core topics center on interfaces and component life-cycle. Often this means access control, authentication, governance, encryption, information integrity and confidentiality. This C’s slogan is “Secure the components.”
Excerpt from Kubernetes “4C”, which inspired Computas “6C” (https://kubernetes.io/docs/concepts/security/overview/)

While the topic list may seem exhausting, there are three ways we constrain the scope. (a) As mentioned, the “6C”s focus is on cloud, containers and DevOps. Other topics, as the figure above shows, are dealt with in a more cursory manner. (b) As mentioned we often do a broad and brief — meaning days and not weeks — assessment of the state of security of a project before we possibly do “deep dives” into particular areas. This leads to (c) a prioritization of issues. We work on the most important ones.

The outcome of a brief assessment as mentioned in (b) may be an advisory, i.e. a presentation or a report. The contents are not compliance goals referring to a standard or a company check-list, but a set of recommended actions. Do this, implement this, improve this, etc. Often the recommended actions are more geared towards process — e.g. put in place a way to decide whether incidents are to be transformed into product backlog items or introduce a step that breaks the build if an image dependency is not whitelisted — rather than fix individual security flaws. If a team chooses to do a “deep dive”, we might arrange for a temporary extension of the team, allowing a security expert working with the team for a time. Here the focus is more on operational capacity, doing things, than writing down actions for someone else to do.

I hope that was inspiring. Below, I’ve included some of the resources we often rely on.

—

Chain:

Core:

Components:

Cluster:

Container:

Code:

Practical security at the nexus of Kubernetes, Devops and Cloud was originally published in Grensesnittet on Medium, where people are continuing the conversation by highlighting and responding to this story.