Kubernetes (K8s) security is hard because of its multi-layered architecture. There is an infrastructure layer, container runtime, network runtime, k8s control plane, K8s identities and entitlements, and K8s resources. Couple this with multi-cluster architecture and the problem suddenly becomes a lot more complex. Imagine a telco deployment with a k8s orchestrated management control plane, along with a set of regional clusters and each regional cluster managing a set of edge clusters. The problem of managing security in such deployments becomes a lot of challenging!
Source: Cloud Native Security whitepaper v2
There are multitudes of tooling available to secure different aspects of deployment. Security teams must create rules/policy sets for each of these tools/engines. This is a difficult task and doing this at the scale of several thousand edge site locations makes it an intractable problem.
There are several issues if the security team has to deal with all these engines/tools individually. E.g.:
What happens if the engine has to be replaced with something else? Consider the scenario where a CNI might be replaced from Calico to Cilium.
Achieving defense in depth becomes a real problem since the security team must consider the rules/policies set at each layer.
Further, the behavior of workloads might be different on where they are deployed. Using the runtime context to define the security rules might help appropriately justify the security posture.
Applying Kubernetes automation
Kubernetes resource model combined with an operator allows one to specify a desired state and an active reconciliation logic enables the operator to achieve the desired state over a while. Kubernetes Storage operators such as Rook have taken advantage of such automation to simplify the distributed storage systems.
To simplify the security automation, can I specify a security intent and then leverage the k8s automation to handle the security intent in the best possible way within the constraints of the given deployment?
Using the Kubernetes active reconciliation logic, it would be possible to handle the security intent using appropriate rules and policy sets that are auto-generated as part of the reconciliation logic.
Introducing Nimbus for Security Intent Automation
Nimbus aims to decouple security intents from its actual implementation i.e., use of policy engines and corresponding policies and rules. Nimbus intends to bring in abstraction for security intents wherein the user specifies the security intent and the Kubernetes operator figures out the best implementation method available given the deployment.
● An Intent might get translated into a set of policies and not necessarily a single policy thus providing a multi-layer defense. For example, an intent such as "Do not allow privilege escalation" could get translated into admission controller policy and system policy as handled by runtime security engines such as KubeArmor.
● An intent could take into consideration runtime behavior and then handle intent implementation. E.g., the intent could be "Do not allow privilege flags for pods that are publicly reachable".
● An intent might be fully or partially satisfied and the bindings clearly show that status.
● An organization can provide a blueprint of intents given a deployment and the operator could go and try to satisfy those intents in best-effort or strict mode.
Design Rationale
Decoupling the intents from the actual rules/policies requires a set of rationales.
● Intents and their parameters should be agnostic to a specific policy engine.
● The intents eventually need to be operationalized and this is handled through a set of policy engine adaptors who understand how to convert the given intent into a rule set that can be handled by the corresponding policy engine.
● Given an Intent, multiple adapters can emit policies for their respective engines. This allows it to handle defense in depth approach.
● Nimbus Operator watches for external events and can fulfill intents based on it.
● Ability to understand which intents are fulfilled, partially or fully.
Nimbus Vision
Nimbus aims to provide:
● a standard Kubernetes-based framework to automate the handling of Security Intents
● A set of policy adapters that can convert the intents to corresponding rules/policies
● Handling of Intents as k8s resources such that the generated adapter based policies/rules can be mapped back to the Intent.
Nimbus Security Blueprints
Nimbus aims to further standardize the creation of blueprints in the context of existing verticals such that users can share and use the industry best practices.
● Blueprints: Vertical specific bundle of security intents
● Intents: High level security requirements
● Policies/Rules: Actual policies/rules that are used by the policy engine to enforce a given security control.
Security Intents Schema
title: Scenario-title description: Detailed description of the scenario severity: High/Medium/Low tags: - [ “oran”, “5gcore”, “generic” ] detectionMethods: # Mechanisms to detect the threat - name: Application log tag: - mitre/ds0015 description: Description # Optional url: https://... mitigationMethods: # Mechanisms to mitigate the threat - name: Update Software tag: - mitre/ds0015 description: desc url: https://... securityIntents: - [ “sample-si-1.yaml”, “sample-si-2.yaml” ] securityIntentBinding: - sample-si-binding.yaml preDeploymentConsiderations: [ ] references: - name: ref1 url: https://... |
The security intents schema is maintained in this (5GSEC/security-intents) code repository.
Sample use-case
Prevent DNS Manipulation
Prevent the use of Software deployment tools at runtime
Conclusion
Future telco deployments will require fully self-service solutions that can leverage the automation capabilities of the k8s deployments. Nimbus is the first engine that instantiates this vision by providing a specific implementation leveraging k8s operator and resource model.