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.

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.

Applications and workloads running on Kubernetes environment, just like any application, requires secrets to gain access to data stored in the database, 1st / 3rd party services or APIs.
Secrets, however, are only effective if they actually remain secret. When secrets leak, attackers will be able to gain access to sensitive data, services or APIs and can potentially put your entire environment and business at risk.

Everyone is talking about Kubernetes these days, and it’s no secret that Kubernetes has emerged as the leading container orchestration tool. There are a variety of reasons for that, ranging from Kubernetes’s open source, community-based development model to helpful technical features like pod security policies and automatic load balancing.