Cloud Security Solutions.

Kloudone provides complete cloud security solutions including

  • Compliance & Monitoring
    We deliver compliance for ISO 27001, PCI-DSS, Hipaa and much more.
  • Container and service mesh Security
    We deliver a Cloud Native container firewall with Fine grained security for various parts of the container stack.
Kubernetes & Docker

We help deliver container specific security for Kubernetes and Docker using eBPF and Cilium

Envoy & Istio Security

We help secure envoy, istio and other service mesh components using eBPF / Cilium

L3 / L7 Firewall

We deliver the most robust protection for your L3 / L7 components using eBPF

Identity Solutions using SPIFFEE

Kloudone Provides identity management solutions for containers using SPIFFEE

Cloud Security Primer

Container security primer:

What are the different layers of container and how do we secure them?

The container host operating system Containers make it easier for developers to build and promote an application and its dependencies as a unit. Containers also make it easy to get the most use of your servers by enabling multitenant application deployments on a shared host. Your approach to securing containers should be the same as your approach to securing any running process on Linux.

Dropping privileges is important and still the best practice. Even better is to create containers with the least privilege possible. Containers should run as user, not root. Next, make use of the multiple levels of security available in Linux.

Linux namespaces, Security-Enhanced Linux (SELinux), Cgroups, capabilities, and secure computing mode (seccomp) are five of the security features available for securing containers running on Red Hat® Enterprise Linux.• Linux namespaces provide the fundamentals of container isolation. A namespace makes it appear to the processes within the namespace that they have their own instance of global resources. Namespaces provide the abstraction that gives the impression you are running on your own operating system when you are inside a container.

Linux namespaces provide the fundamentals of container isolation. A namespace makes it appear to the processes within the namespace that they have their own instance of global resources. Namespaces provide the abstraction that gives the impression you are running on your own oper-ating system when you are inside a container

SELinux provides a layer of security to keep containers isolated from each other and from the host. SELinux allows administrators to enforce mandatory access controls (MAC) for every user, application, process, and file. SELinux is like a brick wall that will stop you if you manage to break out of (accidentally or on purpose) the namespace abstraction.

Cgroups (control groups) limit, account for, and isolate the resource usage (e.g., CPU, memory, disk I/O, network) of a collection of processes. Use Cgroups to ensure your container will not be stomped on by another container on the same host. Cgroups can also be used to control pseudo-devices — a popular attack vector.

Linux capabilities can be used to lock down root in a container. Capabilities are distinct units of privilege that can be independently enabled or disabled. Capabilities allow you to do things such as send raw IP packets or bind to ports below 1024. When running containers, you can drop multiple capabilities without impacting the vast majority of containerized applications.

Container security starts with finding trusted sources for base images. Even when using trusted images, though, adding applications and making configuration changes will introduce new variables.

Finally, a secure computing mode (seccomp) profile can be associated with a container to restrict available system calls

Containers from trusted sources

It is paramount that the software supply chain of images for containers comes from trusted sources of images. These images are typically signed and have vulnerability scans done before the containers are available for consumption.

When gathering container images, ask the following questions
  • Are the container images signed (from trusted sources)?
  • How quickly and how often will the container be updated?
  • Are known problems identified, and how will they be tracked?
  • Does the container have an identity and is a standard identity management solution used to manage container security.
  • Are there known vulnerabilities in my container?

Container registries

Enterprise apps need to manage access to internally built images in the same way as other types of binaries are managed. There are a number of private registries that support storage of container images that could be used for secure distribution of container images.

An example of compliance
Before we define ‘policy-based compliance’, it helps to gain a solid understanding of what compliance means in the world of software development. Generally speaking, compliance is a set of standards for recommended security controls laid out by a particular agency or industry that an application must adhere to. NIST SP 800-190 is an example of a standard which addresses the security concerns that are associated with application container technologies.

Security and the build process

Managing the build process is key to securing the software stack. Adhering to a “build once, deploy everywhere” philosophy ensures that the product of the build process is exactly what is deployed in production. It’s also important to maintain the immutability of your containers — in other words, do not patch running containers; rebuild and redeploy them instead. It also makes sense to leverage vulnerability scanners to scan containers for vulnerabilities within the build>

A best practice for application security is to integrate automated security testing into your build or CI process. For example, integrate:
  • Static Application Security Testing (SAST) and Dynamic Applications Security Testing (DAST) tools like HP Fortify and IBM AppScan.
  • Scanners for real-time checking against known vulnerabilities like Black Duck Hub and JFrog Xray. Tools like these catalog the open source packages in your container, notify you of any known vulnerabilities, and update you when new vulnerabilities are discovered in previously scanned packages

A Policy based compliance approach.

Kloudone follows a policy-based compliance approach. But what do we mean by ‘policy based compliance’? And what are some of the best practices organizations can adopt to help achieve their own compliance needs? In this post we will first define compliance, and then cover a few steps development teams can take to help to bolster their container security.

What do we mean by ‘policy-based’? Policy based compliance means adhering to a set compliance requirements via customizable rules defined by a user. In some cases, security software tools will contain a policy engine that allows for development teams to create rules that correspond to a particular security concern addressed in a compliance publication.

Role of OPA

OPA is a full-featured policy engine that offloads policy decisions from your service. You can think of it as a concierge for your service who can answer detailed questions on behalf of your users to meet their specific needs. OPA could be rolled out within your container security app to ensure that policy compliance rule definitions and decisions are done In a centralized manner.

Identity and access management using SPIFFE

SPIFFE, the Secure Production Identity Framework for Everyone, is a set of open-source standards for securely identifying software systems in dynamic and heterogeneous environments. Systems that adopt SPIFFE can easily and reliably mutually authenticate wherever they are running.

OPA and SPIFFE extend the security capabilities available to cloud and container workloads, helping to fill perceived gaps in existing security controls.

Service identity is all about understanding what is running where and defining what different components are allowed to do in a distributed environment.

SPIFFE has also been designed to be cloud-native, meaning that it is optimized to work in stateless environments where containers are started, stopped and moved frequently. James said that SPIFFE can inject identity at runtime, as workloads startup. SPIFFE uses public key cryptography (PKI) and Transport Layer Security (TLS) to authenticate workloads. The SPIFFE approach also includes a TLS Certificate Authority (CA) component to enable cryptographic keys to remain within an organization's control.

Container orchestration: Securing the container platform When managing container deployment at scale, you need to consider:
  • Which containers need access to each other. How will they discover each other?
  • How you control access to — and management of — shared resources, like network and storage.
  • How do you provision rules for access and network restrictions How do you isolate individual containers in the eventuality if it being compromised
  • How you monitor container health.
  • How you automatically scale application capacity to meet demand.
  • How to enable developer self-service while also meeting security requirements.

Kloudone’s approach to container security:

Kloudone provides container security as a managed solution for enterprises migrating to container workloads. We will help deliver a container based, cloud native firewall that will help provide fine grained security and access control for your container workloads.

Our solution consists of the following
  • Cloud compliance with automated runtime checks and third party audit (if required) to ensure compliance with HIPAA, SOC2, ISO 27001, PCI-DSS and more.
  • Service mesh security – Istio, Envoy, Mesos
  • L3/L7 firewall
  • Encrypted pod / host communication.
  • IPVLAN support
  • Load balancing.


We currently leverage eBPF (extended Berkeley Packet Filter) for security. What is eBPF?
  • eBPF is a Low level Linux Kernel based virtual machine that runs precompiled bytecode instructions.
  • eBPF operates in the linux kernel, and programs can process network traffic even before it hits the kernel.
  • Facebook’s loadbalancer (katran) is built using eBPF and XDP
  • Cloudflare’s DDOS service is built on top of eBPF
Our full suite of solutions for container include Identity management using SPIFFE and OPA.


Get in touch with us.

Who do we do it for?

$200 Billion US Public Hardware and Software Company

KloudOne's team led re-engineering for a multi-billion dollar enterprise in the bay area for Lift and Shift to GCP Legacy Product Modernization

$10M CyberSecurity Software Company

KloudOne led legacy product re-development including Re-engineering complex pieces for simplicity Introducing large scale data processing pipeline Lifting / Shifting applications to make it cross cloud compatible

Telecom grade mobile advertising engine

KloudOne led product development including Introducing large scale data processing pipeline Lift and shift of existing components form AWS to GCP Build a DMP at scale(100k QPS) CI/CD pipeline with Docker/Kubernetes