CNCF Demo

This project is an interactive, 'Choose Your Own Adventure'-style presentation designed to guide an anthropomorphized application from source code on a developer's laptop to a running application in production. The journey covers critical decision points in the software lifecycle, including app design, testing, security, container image building, deployment strategies, and observability.

Participants navigate the trek by voting on paths, aiming to utilize CNCF (Cloud Native Computing Foundation) projects while avoiding pitfalls and dead-ends.

This project explores different methods for generating Workload Identity. Currently, the following three options are identified as potential paths, though they are not yet implemented in this repository:

1. SPIFFE: An open standard for providing identity to workloads.
2. SPIRE: The runtime implementation of the SPIFFE standard.
3. Athenz: An open-source identity and access management service.

If you wish to contribute an implementation for any of these choices, please open an issue in the repository.

When defining and deploying an application to a cloud-native environment, several categories of configuration must be addressed:

• Container images: Declaring the image name and registry, managing registry credentials, and establishing an update strategy for image values.
• Application-specific configuration: Environment-dependent values (e.g., different database connection strings for dev vs. prod) and credentials for connecting to third-party services.
• Infrastructure configuration: Defining the physical or cloud provider, account details, compute access methods, and permission management.
• Kubernetes-specific components: Managing resource objects such as Deployments, Roles, Namespaces, Services, PersistentVolumeClaims, ConfigMaps, and ServiceAccounts.

KubeArmor is a cloud-native runtime security engine designed to monitor systems at the kernel level, alert on anomalies, and prevent security issues.

Key Features:

• Inline Enforcement: Unlike tools that only alert after an attack, KubeArmor can prevent attacks from succeeding by failing the attempted action alongside the alert.
• Mechanism: It uses Linux Security Modules (LSMs) and hooks directly into the Linux kernel using eBPF for high performance and safe monitoring.
• Policy Support: It can supply recommended policies based on industry standards.

For more details, visit the Official site.

Falco is a cloud-native threat detector that identifies events that could endanger a system.

How it works: Falco monitors events from two primary source types:

1. Kernel Events: Captured via Falco's kernel module or an eBPF probe.
2. Plugin Events: Includes Kubernetes audit events, Okta events, and other third-party integrations.

Core Components:

• Falco Rules: YAML files that define the specific conditions required to trigger an alert. The community maintains approximately 70 standard rules.
• Alert Forwarding: Alerts can be sent to over 50 compatible destinations (e.g., Slack, Telegram).
• Falco Talon: A sub-project used to automate responses to alerts, such as killing a container or initiating additional data collection when a specific threat is detected.

For more details, visit the Official site.

The progressive delivery implementation currently supports Istio. Other service meshes and ingress controllers are listed but have not yet been implemented in this demo:

• Istio (Implemented)
• Cilium (Not implemented)
• Kuma (Not implemented)
• Network Service Mesh (Not implemented)
• Linkerd (Not implemented)

If you wish to contribute an implementation for one of the missing components, please open an issue in the repository.

The Secrets Store CSI Driver (SSCSID) allows Kubernetes pods to access secrets from external vaults without ever creating a native Kubernetes Secret object.

Core Mechanism:

• CSI Integration: Uses the standard Container Storage Interface to interface between Kubernetes and external storage/vault vendors.
• Volume Mounting: Mounts secrets from the vault directly into the pod as a temporary filesystem volume.
• Identity-Based Access: Leverages workload pod identity to authenticate with the vault, ensuring strict principle of least privilege (the pod only accesses what it is explicitly authorized to access).

Primary Advantage:

• Reduces the footprint of sensitive data within the Kubernetes cluster by avoiding the storage of secrets in the Kubernetes etcd database.

For more detailed implementation guides, see sscsid.md.

This project presents four distinct architectural choices for implementing APIs via Custom Resource Definitions (CRDs) and managing state via Controllers. You can choose between these platforms depending on your requirements for control plane management and application delivery:

1. Crossplane: A control plane of control planes.
2. KubeVela: A modern application delivery platform using the Open Application Model (OAM).
3. kro: A tool for composing Kubernetes resources.
4. Kratix: A platform for delivering your own internal developer platform (IDP).

The cncf-demo repository is structured as a 'Choose Your Own Adventure' guide for navigating the complex landscape of Cloud Native technologies. The project is divided into two primary conceptual journeys:

1. The Treacherous Trek to Production: Focuses on the operational lifecycle of an application, covering observability (Tracing, Data Pipelines), networking (Service Mesh), deployment strategies (Progressive Delivery), and cost management.
2. Internal Developer Platform (IDP) Construction: Focuses on building the underlying platform infrastructure, covering API/CRD management, Policy enforcement, GitOps state synchronization, and Workflow automation.

Each path provides multiple technology choices (e.g., Jaeger vs. Zipkin for tracing, or Argo CD vs. Flux for GitOps) to demonstrate how different CNCF tools integrate and solve similar problems.

The 'Security Misfits' section of this project presents two potential security implementation paths that are currently placeholders for future contributions:

1. Confidential Containers: An implementation path based on the Confidential Containers project.
2. ContainerSSH: An implementation path based on ContainerSSH.

Note: Neither of these options is currently implemented in this repository. If you wish to implement one of these, please open an issue to contribute.