Support for Generating an SBOM for the Entire Kubernetes Environment, Including Namespace, Pods, Services, Images and Network Policy Details

[RajikaJain]

Hello,
I am working with a Kubernetes cluster that has multiple namespaces, each running several applications. These applications are deployed across various pods, and network policies are implemented for access control, as well as ingress and egress traffic management.
I would like to know if bom currently supports or has plans to support the generation of a Kubernetes SBOM (KBOM) that includes the following details:

1. Namespace Information: Detailed breakdown of applications running within each namespace.
2. Pod and Service Information: Information about pods and services, including the container images being used, their versions, and any relevant metadata.
3. Network Policies: Details of network policies applied within the namespaces for controlling ingress and egress traffic.
4. Configuration Files: Ability to capture and include Kubernetes configuration files (YAML/JSON) within the SBOM.
5. Dependency Analysis: Analysis of dependencies across the cluster, considering inter-pod communication and external dependencies.
6. Security Context: Details regarding the security contexts defined for each pod, including policies, roles, and any enforced security mechanisms.
   Additionally, I would like to know if bom can generate a comprehensive in-toto provenance attestation for the entire Kubernetes environment, encompassing all these elements.
   If these features are not currently available, is there a roadmap or ongoing work to incorporate them? Any guidance on how to achieve this with the current capabilities of bom or potential workarounds would be greatly appreciated.
   Thank you for your time and consideration.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten