Security can certainly be a broad brush topic. As a software engineer, you design and build to the best of your ability. In delivery methodologies of years gone by, sometimes security can be viewed as an afterthought e.g running security testing last before deploying. Today with the DevSecOps movement, one more set of concerns moves left towards the developer which is now security. Adding complexity with Kubernetes and all of the shift left concepts that come along with Kubernetes, there is a lot on software engineers’ collective plates. As workloads become more critical that are run on Kubernetes, a separation starts to occur similar to the virtual machine days between the developer and the environment e.g no production access. Let’s take a dive into some security challenges and basics for developers whose workloads are headed to Kubernetes.
Is it the Cluster or the Workload or Between?
Kubernetes is about to celebrate its eighth birthday being on GitHub. Today, it is not novel to run something on Kubernetes. Though Kubernetes is old enough for business controls to boil into system design e.g developers should not have direct access to production clusters or namespaces. In the early days of Kubernetes, was not uncommon for development teams to run their own clusters. As the criticality of the workloads increased, that model is not popular in favor of a system [well platform engineering] team running and tuning Kubernetes clusters to accept workloads.
Kubernetes security is split just as paradigms before Kubernetes. The infrastructure e.g Kubernetes and the workloads that are running on Kubernetes. Software engineers should focus on ownership of their workloads and platform engineers should focus on ownership of the Kubernetes platform itself. Though the lines really start to blur with all of the items that shift left. For example who owns network security when a Service Mesh is running? Maybe the line in the sand is that the platform engineering team focuses on the provider level for example making sure Istio is running a stable and secure version but the developers are responsible for the configurations, the custom-resource-definations, they send to Istio.
Adding the “between” part between cluster and workload is the pipeline. With the rise of Continuous Delivery and GitOps models, even what is facilitating the on and offboarding of workloads to Kubernetes clusters can be a surface area for attack. A good example of the between security surface area was the SolarWinds Attack in 2020. Post SolarWinds Attack, chain of custody practices such as container signing, and projects like Cosign are gaining popularity. The main piece of advice for a developer is to focus on the workload. Changes in security posture on the cluster and the “between” could require changes to the workload or configuration a developer has to write, but the main focus of a developer is the workload itself.
Modern Application Security Fundamentals
From a developer perspective, application security boils down to “what to focus on”. An oversimplified view of application security can be broken down into what, where, and inputs/outputs of the application. So as a developer, you’ll need to focus on what, where, and the I/O.
What Are You Leveraging?
There is no question that software ages like milk not like wine. Most modern software leverages third-party open-source; components that no one in the organization has written. From a software engineering perspective, delivering functionality requires multiple pieces of open source. Deep contributor level expertise on these projects/pieces/components is usually not in-house. So software engineers would more be focused on functionality and a compelling event to migrate from one version to the next. Adding to the complexity is the nature of transitive dependencies. Open source is also built on open source and for example, if you are leveraging a popular piece of open source like Apache Kafka, there might be dozens or hundreds of transitive dependencies that come along with Kafka.
Over the last several years taking learnings from the manufacturing industry, bill-of-material or BOMs have become popular in the software industry. Cataloging dependencies is a key pillar of the SBOM movement and legislation here in the United States. With a BOM/SBOM, tooling can even link those dependencies to known vulnerabilities which are becoming more commonplace with dependency and container scanning platforms.
Shipa displays SBOM information tied to vulnerabilities.
From a prioritization perspective, what has a relationship with where something is running. If something is deployed, there is a higher sense of urgency than an image being in a registry.
Where Are Your Services?
Compensating and perimeter controls have focused on limiting access to production. A common business control is “developers can not access production” or “the author can not be the deployer”. A big draw of Kubernetes is the parity between environments. A Kubernetes manifest should be similarly respected on different clusters. Though because of this ease of change, many organizations do not give developers kubectl access to production. A duality of securing production from unintended access/changes and workloads that are actually deployed have a higher significance to fix vs items hanging out in a registry or repository.
Shipa provides role-based access to developers so they can get to logs of running applications without any code changes or re-deployments of applications.
Adding to the complexity and fog of development is the rise in microservices. Now because services are becoming more granular, multiple deployments and services make up functionality.
Shipa displays a geographic breakdown of workloads and additional statistics.
Communication between these services can be subject to a myriad of rules. Because of the ever-increasing shifting left mentality, networking policies that would have been handled by a networking or infrastructure engineering are showing up as Kubernetes manifests. Having common sense access to data and metrics about your services and understanding what is actually deployed and how they are communicating is key to application security.
Traffic Comes In, Traffic Goes Out
Another basic pillar of application security is sanitizing your inputs and ironically outputs. In a microservices world, service to service communication is key and user responses are aggregate responses from multiple services. With a focus on Kubernetes, a common design is to limit ingress and egress communication with services.
Shipa can create, modify, and visualize Kubernetes Networking Policies.
For example, if your service takes public traffic, accepting all traffic is acceptable. If your service let’s say communicates with a login or authentication service, limiting ingress and egress of that service to only come from the public service itself [e.g not a direct external connection] is a common design. In Kubernetes, configuring that would require some expertise in Kubernetes Networking Policies and/or the Service Mesh implementation of that. With a Shipa, you can configure ingress and egress policies in plain English. Shipa is purpose-built and laser-focused on reducing developer toil in any form when it comes to Kubernetes.
Shipa, Your Partner in Strengthening Developer Security Knowledge
With the recent introduction of Shipa Insights, Shipa is pushing forward with surfacing security, policy, and conformance information Shipa makes it easy to practice hygienic practices when focusing on the what, where, and I/O of your services.
Shipa provides compliance reports on policies.
Be sure to sign up for Shipa today. Check out this great video that Bruno created walking through step by step how to start providing an excellent DevSecOps experience to your developers.
Cheers,
-Ravi
