Kubernetes namespaces - they’re an essential feature for building modern cloud architectures. Namespaces let you split up a single cluster into multiple “virtual clusters”. Resources like pods, replicasets, and deployments all live in namespaces. You can think of a namespace as being a resource’s last name - it specifies which family the resource is part of - and normal resources can have one and only one namespace (There are exceptions like the Node resource which is cluster-wide and doesn’t belong to any namespace). If you don’t think you’re using namespaces on your cluster then you’re wrong. You’re actually just putting everything into the default namespace.
A security issue was discovered in the kube-apiserver that could enable a privilege escalation from a compromised node.
Alcide Logs and Coralogix
Ingress APIs manage external access to the services in a cluster, typically HTTP. This would generally be implemented as an API Gateway style of traffic routers that relay traffic to proxied services through a common entry point. The user would be left to control when and how to publish a service by using a declarative definition of the desired behavior (with YAML/JSON file).
Last month, the Microsoft Azure Security Center published a fully detailed Threat Matrix for Kubernetes. This article identifies attack vectors unique to a Kubernetes environment. This important contribution is derived from the more generalized MITRE ATT&CK® framework that offers a complex matrix of common attack vectors.
Two security issues were discovered in Kubernetes and disclosed on March 23, 2020 that could lead to a recoverable denial of service in a Kubernetes cluster.
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.
Kubernetes V1.18-alpha.2 is live! The new version introduces an alpha stage field for both Secret and ConfigMap objects to mark their content as immutable.
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.