GitOps is a paradigm that puts Git at the heart of building and operating cloud native applications by using Git as the single source of truth and empowers developers to perform what used to fall under IT operations. This post is part a blog post series covering GitOps and Kubernetes security.
I'm a fan of online surveys. It's a fun, simple, and a great way to check the pulse of our community.
We launched our first survey back in 2018, where we looked at the state of securing cloud workloads. We then continued the motion in 2019 with The Kubernetes Adoption and Usage survey and most recently with the Helm survey, still open for feedback.
In this blog post I'd like to focus on the 2019 Alcide Kubernetes survey. Based on 200 responses from Dev, Ops, Security and Cloud Architects, our survey reveals that 45% of companies are now running Kubernetes in production, while 37% are leveraging hybrid or multi-cloud environments for their Kubernetes clusters.
In this blog I am going to explain why you should avoid exposing every tiny configuration in your SaaS application. I am going to talk about configurations that are related to SaaS deployments. This kind of deployments have the unique property that they are fully deployed and managed by either dev or ops teams.
Publishing a Kubernetes Service
In Kubernetes, a Service is an abstract way to expose an application running on a set of Pods as a network service
With Kubernetes you don’t need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
This post will describe the different ways used to publish a Kubernetes service, the risks harbored and the methods that can be applied to mitigate those risks.
In our recent blog about making Kubernetes logs auditing a viable practice we mentioned that in general, audit logs are used in two ways:
Helm 3 was released yesterday. Here's what it means for security pros.
The Kubernetes container-orchestration system provides a platform for automating deployments
and operations of application containers across clusters of hosts by defining resources as
manageable Objects. Some of these resources can be managed by other resources automatically
while others can be referenced through metadata fields within the object.
What is Pod Security Policy?
The Pod Security Policy, sometimes called PSP in short, is a Kubernetes resource that allows the enforcement of policy rules during the creation phase of a Pod.
When a PodSecurityPolicy resource is created, it does nothing. In order to use it, the requesting user or target pod’s service account must be authorized to use the policy, by allowing the use verb on the policy.