UNCLASSIFIED - NO CUI

Skip to content
Snippets Groups Projects

add uds-core as a conformant stack

Open add uds-core as a conformant stack
micah.nagel/bbtoc:uds-core-bbcs into master
Open Micah Nagel requested to merge micah.nagel/bbtoc:uds-core-bbcs into master
Compare
and
1 file
+ 141
− 0
Compare changes
  • Side-by-side
  • Inline
conformant-stacks/uds-core/uds-core.md 0 → 100644
+ 141
− 0
# UDS Core
Source Code (Repo1): https://repo1.dso.mil/platform-one/distros/defense-unicorns/uds-core
Source Code (GitHub/Upstream): https://github.com/defenseunicorns/uds-core
Vendor: [Defense Unicorns](https://defenseunicorns.com/)
Description: A FOSS secure runtime platform for mission-critical capabilities
Website: https://defenseunicorns.com/uds
Documentation: https://uds.defenseunicorns.com/
License: [Dual licensed](https://github.com/defenseunicorns/uds-core/blob/main/LICENSING.md) AGPLv3 with commercial license option
## General Requirements
- [x] MUST be able to deploy to a CNCF Certified Conformant Kubernetes cluster (or include one within the stack that it deploys)
Explanation/Evidence: UDS Core runs on any non-EOL conformant cluster ([see documentation](https://uds.defenseunicorns.com/reference/uds-core/prerequisites/)). In addition CI testing is done against production distros like [EKS, AKS, and RKE2](https://github.com/defenseunicorns/uds-core/tree/main/.github/test-infra), as well as developer friendly k3d.
- [x] MUST be able to be deployed into fully air-gapped environments with a documented process
Explanation/Evidence: UDS Core is designed to be air-gap native and uses [Zarf](https://zarf.dev/) for deployment. The main published artifact for UDS Core is a Zarf package with all necessary images and manifests included.
- [x] MUST publish all instructions, source code and links to artifacts on repo1
Explanation/Evidence: UDS Core is mirrored to Repo1 [here](https://repo1.dso.mil/platform-one/distros/defense-unicorns/uds-core).
- [x] SHOULD release all core functionality above under an OSI Approved License
Explanation/Evidence: UDS Core is itself licensed AGPLv3. Core technology used by UDS Core includes Zarf ([Apache 2.0](https://github.com/zarf-dev/zarf/blob/main/LICENSE)) and Pepr ([Apache 2.0](https://github.com/defenseunicorns/pepr/blob/main/LICENSE)).
- [x] SHOULD provide a machine-readable compliance report for relevant security controls, to be defined by the BBTOC
Explanation/Evidence: UDS Core includes [compliance documented with OSCAL](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/compliance/oscal-component.yaml) for each application/component included.
- [x] SHOULD be able to be deployed declaratively
Explanation/Evidence: UDS Core deploys with Zarf and primarily leverages upstream helm charts which are all configured declaratively via create-time values set in [`zarf.yaml`](https://docs.zarf.dev/ref/components/#helm-charts) files and deploy-time values set via a [`zarf-config.yaml`](https://docs.zarf.dev/ref/config-files/).
## Service Mesh
- [x] SHOULD configure mTLS for all internal network traffic
Explanation/Evidence: UDS Core deploys [Istio](https://istio.io/) with a [STRICT mTLS policy by default](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/istio/common/chart/templates/peer-authentication.yaml).
- [x] SHOULD use L7 policies for any wide open inbound connections not traversing an ingress
Explanation/Evidence: UDS Core implements L7 policies on several sensitive endpoints, for example [Keycloak's admin and master realm](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/keycloak/chart/templates/istio-admin.yaml).
- [x] MUST Track/document any exceptions
Explanation/Evidence: Any exceptions to this are documented in code with explicit `PeerAuthentication` resources that are limited to single ports where possible. For example metrics-server deploys a [PERMISSIVE exception](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/metrics-server/chart/templates/peerauthentication/metrics-api.yaml) to allow proper API Service communication.
## Policy Engine
- [x] MUST provide documented list of policies, along with enforcement status
Explanation/Evidence: UDS Core uses [Pepr](https://pepr.dev/) for policy enforcement. All policies are documented with implementation/enforcement status in [the documentation](https://uds.defenseunicorns.com/reference/configuration/pepr-policies/#pepr-policy-validations).
- [x] SHOULD base policies off of the [Kubernetes Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) and [Big Bang's Kyverno Policies](https://docs-bigbang.dso.mil/latest/packages/kyverno-policies/docs/policies/)
Explanation/Evidence: Policies are based on these two upstream sources, with explicit links back to Big Bang in [the documentation](https://uds.defenseunicorns.com/reference/configuration/pepr-policies/#pepr-policy-validations) (on the policy name) to clearly identify the upstream connection
- [x] MUST track/document exceptions to these policies
Explanation/Evidence: All exceptions to policies are tracked via an [`Exemption` custom resource](https://uds.defenseunicorns.com/reference/configuration/uds-operator/exemption/). Exemptions in UDS Core provide descriptions to justify why they are necessary (see [example here](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/neuvector/chart/templates/uds-exemption.yaml)).
- [x] SHOULD aggregate reporting of all policies
Explanation/Evidence: Exceptions to policies are easily aggregated by pulling the custom resources from the cluster (`kubectl get exemptions -A`). Pepr also includes the command [`pepr monitor`](https://docs.pepr.dev/v0.45.0/user-guide/pepr-cli/#npx-pepr-monitor) which can be used to easily identify all actions from policies (approvals and denials). This data is also logged out by Pepr and would be accessible in logging tooling/Grafana dashboarding.
## Runtime Security
- [x] MUST provide active detection & alerting
Explanation/Evidence: UDS Core includes NeuVector which provides [automated reporting and notifications](https://open-docs.neuvector.com/reporting/reporting) on security events. UDS Core configures NeuVector to automatically place workloads into a monitoring mode (producing alerts on anomalies) after [36 hours of workload discovery](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/neuvector/values/values.yaml#L27-L28).
- [x] SHOULD block detected threats
Explanation/Evidence: UDS Core partially satisfies this requirement. NeuVector provides prevention of threats when workloads are moved into its [Protect mode](https://open-docs.neuvector.com/policy/modes). By default in UDS Core workloads are only auto-promoted to Monitor mode and the end user must configure NeuVector to move workloads into Protect mode.
- [x] MUST aggregate reporting of all security events
Explanation/Evidence: NeuVector provides [aggregated reporting of all security events](https://open-docs.neuvector.com/reporting/reporting) in its dashboards.
## Network Security
- [x] MUST configure network policies to block all traffic by default
Explanation/Evidence: UDS Core automatically generates a [set of default network policies](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/pepr/operator/controllers/network/policies.ts#L30-L41) that explicitly includes a [deny all policy](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/pepr/operator/controllers/network/defaults/default-deny-all.ts).
- [x] MUST configure network policies to allow only necessary traffic
Explanation/Evidence: Deployed services within UDS Core add only the necessary ingress/egress policies beyond the default deny. Policies are defined and generated based on a [`Package` custom resource](https://uds.defenseunicorns.com/reference/configuration/custom-resources/packages-v1alpha1-cr/#allow), with minimal ingress/egress allowed using selectors and ports as applicable (see [example here](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/grafana/chart/templates/uds-package.yaml#L37)).
- [x] MUST have the ability to protect exposed admin endpoints via an IdAM system (internal or external) or other external security controls
Explanation/Evidence: UDS Core protects all admin endpoints by default using a deployment of Keycloak. This is configured via the [`Package` custom resource `sso` spec](https://uds.defenseunicorns.com/reference/configuration/custom-resources/packages-v1alpha1-cr/#sso) and individual application configuration where necessary. For example, Grafana generates a SSO client [here](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/grafana/chart/templates/uds-package.yaml#L10-L18) and is configured to use that SSO client with the [upstream values](https://github.com/defenseunicorns/uds-core/blob/v0.35.0/src/grafana/values/values.yaml#L35-L53).
- [x] SHOULD have the ability to protect exposed regular endpoints via an IdAM system (internal or external)
Explanation/Evidence: UDS Core does not deploy any regular/tenant endpoints by default, but does provide the same mechanism via the [`Package` custom resource `sso` spec](https://uds.defenseunicorns.com/reference/configuration/custom-resources/packages-v1alpha1-cr/#sso) to generate and configure Keycloak clients. This also provides options to automatically protect applications with AuthService if the application does not natively support OIDC/SAML configuration.
- [x] SHOULD segment admin endpoints via a non-public or alternate ingress gateway
Explanation/Evidence: UDS Core provides 2 gateways by default, admin and tenant. Endpoints are exposed via the [`Package` custom resource `expose` spec](https://uds.defenseunicorns.com/reference/configuration/custom-resources/packages-v1alpha1-cr/#expose) with a requirement to choose a gateway for the endpoint. [Documentation](https://uds.defenseunicorns.com/reference/uds-core/dns/#bundle-configuration) is also included noting how to keep the admin gateway private (depending on the cloud/other load balancer configuration).
- [x] MUST track/document exceptions to these policies
Explanation/Evidence: All exposed endpoints, network policies, and SSO configuration is clearly identified in the `Package` custom resource. Any overly permissive network policies or public endpoints are clearly defined in that custom resource for a given application.
## Supply Chain Security
- [x] MUST provide SBOM data if deploying images from a source without signed SBOM attestations. If relying on registry-provided SBOMs, the stack MUST provide sufficient listings of images to accurately retrieve the attestations
Explanation/Evidence: UDS Core's artifacts are published as Zarf packages which include a [full SBOM by default](https://docs.zarf.dev/ref/sboms/). SBOMs for a specific version of UDS Core can be viewed by following the [upstream Zarf documentation](https://docs.zarf.dev/ref/sboms/#viewing-a-packages-sbom).
- [x] MUST provide cryptographic verification of software releases and/or software artifacts (e.g. signed images)
Explanation/Evidence: UDS Core publishes several versions of each release, utilizing different image sources. The hardened `registry1` releases source all images from Ironbank. Images in these release versions are signed by Ironbank and can be verified by following [their documentation](https://docs-ironbank.dso.mil/tutorials/cosign/).
- [x] MUST provide regular non-embargoed CVE data for all assets or publish to a public feed
Explanation/Evidence: For the `registry1` releases of UDS Core, CVE data is publicly accessible via the [VAT tool](https://vat.dso.mil/vat) as well as the VAT [image attestations](https://docs-ironbank.dso.mil/tutorials/cosign/#attestations) able to be pulled from the Registry1 registry. Other image sources can easily be scanned using the SBOM with tooling like [`grype`](https://github.com/anchore/grype).
## Ops Support
- [x] MUST provide either documentation or a process to configure new workloads in the cluster to leverage the security features above
Explanation/Evidence: As noted, all security functionality provided in UDS Core is driven with the `Package` custom resource. Documentation for this custom resource is provided [here](https://uds.defenseunicorns.com/reference/configuration/uds-operator/package/).
- [x] SHOULD provide logging and metrics collection for all workloads
Explanation/Evidence: UDS Core includes [Vector](https://vector.dev/) and [Loki](https://grafana.com/oss/loki/) to handle log collection and storage as well as [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/oss/grafana/) to provide metrics collection and visualization (see full capability list [here](https://uds.defenseunicorns.com/overview/uds-structure/#uds-core-capabilities)). Logs from all workloads are automatically collected (to include host logs). Metrics for all applications within UDS Core are also collected, with options to monitor additional applications using the [`monitor` spec in the `Package` custom resource](https://uds.defenseunicorns.com/reference/configuration/custom-resources/packages-v1alpha1-cr/#monitor).
- [x] SHOULD provide disaster recovery capabilities
Explanation/Evidence: UDS Core provides [Velero](https://velero.io/) for cluster backup and restore (see full capability list [here](https://uds.defenseunicorns.com/overview/uds-structure/#uds-core-capabilities)).

UNCLASSIFIED - NO CUI