Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DRAFT/PROPOSAL] change naming/documentation approach from 'Airgapped Docs' to offline documentation #113

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/airgapped-docs/_category_.json
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
{
"label": "Airgapped Docs",
"label": "Offline Documentation",
"position": 6,
"link": {
"type": "generated-index",
"description": "Airgapped-Capable Docs for the Entire Rancher Product Portfolio"
"description": "Airgap Available Docs for the Entire Rancher Product Portfolio"
}
}
6 changes: 3 additions & 3 deletions docs/airgapped-docs/installation.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Downstream Clusters

Run the following Helm command to install Airgapped Docs chart, substituting your registry in:
Run the following Helm command to install the `airgapped-docs` chart, substituting your registry in:

```bash
helm install -n carbide-docs-system --create-namespace \
Expand All @@ -16,11 +16,11 @@ Check the status of the rollout:
helm status -n carbide-docs-system airgapped-docs
```

You should now see `Airgapped Docs` on the left menu of your Explore Cluster.
You should now see `Airgapped Docs` on the left menu of your cluster.

## Selecting Documentation for Low-Compute Environments

There may be situations where you are running in a low-compute, low-resource environment or are not using specific products and do not want to utilize specific documentation from Airgapped Docs. For those situations, you can disable specific products during installation, such as:
There may be situations where you are running in a low-compute, low-resource environment or are not using specific products and do not want to utilize specific offline documentation. For those situations, you can disable specific products during installation, such as:

```bash
# Disable neuvector docs
Expand Down
16 changes: 8 additions & 8 deletions docs/airgapped-docs/introduction.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,17 @@
# Introduction

This page will walk through installation and usage of the Airgapped Docs component of Rancher Government Carbide.
This section will walk through installation and usage of the offline documentation for Rancher Government Carbide.

## IOC Expectations
## What's included?

As our product is still at Initial Operation Capability (IOC), there are some expectations to level-set:
When in an airgap, having accessibile documentation can be critical to mission success, especially while troubleshooting problems.

- Installation and packaging is still in progress and improving.
Carbide offline docs give users access to documentation for Carbide and the entire supported Rancher product porfolio, right from the cluster menu. This includes convenient options like query and copy/paste shortcuts.

If you see issues and areas for improvement, please submit Github issues [here](https://github.com/rancherfederal/carbide-charts/issues).
## IOC Expectations

## What is this?
As our product is still at Initial Operation Capability (IOC), there are some expectations to level-set:

When in an airgap, having accessibility to documentation can be critical to mission success, especially while troubleshooting problems.
- Installation and packaging is still in progress and improving.

Carbide Airgapped Docs will give Rancher supported users access to documentation for not only Carbide itself, but the entire supported Rancher product porfolio. This includes capabililites like query and copy/paste shortcuts.
If you see issues and areas for improvement, please submit Github issues [here](https://github.com/rancherfederal/carbide-charts/issues).
6 changes: 3 additions & 3 deletions docs/airgapped-docs/prereqs.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Prerequisites

In order to utilize Airgapped Docs, you will need the following prerequisites:
In order to utilize offline documentation, you will need the following prerequisites:

- **Rancher v2.7.0 or higher:** https://ranchermanager.docs.rancher.com/integrations-in-rancher/rancher-extensions
- **Helm:** https://helm.sh/docs/intro/install
Expand All @@ -10,7 +10,7 @@ It is also assumed you have followed all of the Carbide Secured Registry (CSR) d

This means you have:
- seeded your registry with the images from the CSR
- the carbide helm charts available for use
- the Carbide helm charts available for use
- configured k3s/rke2 to use your registry
- configured Rancher Manager to use your registry
- configured Rancher to use your registry
- setup policy enforcement to only allow images from the CSR
2 changes: 1 addition & 1 deletion docs/airgapped-docs/uninstall.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

## Downstream Clusters

On each downstream cluster, run the following command to uninstall Airgapped Docs:
On each downstream cluster, run the following command to uninstall the offline documentation:

```bash
helm uninstall -n carbide-docs-system airgapped-docs
Expand Down
22 changes: 9 additions & 13 deletions docs/registry-docs/introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,30 +5,26 @@ This page will walk through IOC expectations of the hardened registry and what e
## IOC Expectations
As our product is still in the IOC phase, there are some expectations to level-set:

* IOC users can expect tooling and processes to be changed, improved and streamlined continuously as we strive to improve the Carbide offering.
* IOC users can expect tooling and processes to be changed, improved, and streamlined continuously as we strive to improve the Carbide offering.

> **DISCLAIMER**: The Secured Registry (rgcrprod.azurecr.us) is _not_ intended to be used as the primary registry for running Kubernetes clusters. It is only intended as the acquisition point to obtain the Carbide secured images. Customers should seed their own private OCI registries, and use that registry for their Kubernetes clusters.

If you see issues and areas for improvement, please submit Github issues [here](https://github.com/rancherfederal/carbide-docs/issues).
If you see areas for improvement, please submit Github issues [here](https://github.com/rancherfederal/carbide-docs/issues).

## What is this?
Here at Rancher Government Solutions, we take the security of our products seriously. Products like `rke2` are tailor built to address the "secure by default" needs of the federal government, while still maintaining the same ease of deployments that our users have come to love from Rancher products.
Here at Rancher Government Solutions, we take the security of our products seriously. Products like `rke2` are tailor-built to address the "secure by default" needs of the federal government, while still maintaining the same ease of deployments that our users have come to love from Rancher products.

The introduction of Carbide Secured Registry (CSR) marks the next big step we are taking to continually enhance our products emphasis on security, this time by directly addressing the supply chain.
The Carbide Secured Registry (CSR) enhances our products' emphasis on security, this time by directly addressing the supply chain.

Now, as an alternative to the "upstream" hosted images from Docker Hub, securely built images can now be sourced from the Carbide Secured Registry (CSR), and come with the following enhancements:
Now, as an alternative to the "upstream" hosted images from Docker Hub, securely built images can be sourced from the Carbide Secured Registry (CSR), and come with the following enhancements:

- Attested build artifacts for core Rancher products (images, sbom's, and vulnerability reports)
- Attested build artifacts for core Rancher products (images, SBOMs, and vulnerability reports)
- Securely built on Rancher Government's internally hosted Secure Software Factory (conforming to the [DoD Reference Architecture](https://dodcio.defense.gov/Portals/0/Documents/Library/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20-%20CNCF%20Kubernetes%20w-DD1910_cleared_20211022.pdf) and [CNCF Best Practices](https://project.linuxfoundation.org/hubfs/CNCF_SSCP_v1.pdf))

Quantifiably measuring the improvements that Carbide Secured Registry (CSR) provides is difficult considering the early stage of standards around supply chain security. However, initial measurements can be gleaned from the Linux Foundation's [SLSA](https://slsa.dev) levels.

The Carbide Secured Registry (CSR) was designed from the ground up to build the foundation for the eventual achievement of SLSA 4, or in other words, the most guarantee in a secure software supply chain. Specifically, this means introducing the following capabilities:
The Carbide Secured Registry (CSR) was designed to comply with the highest level of [SLSA standards](https://slsa.dev) (L3) for supply chain security. Specifically, this means introducing the following capabilities:

- Fully defined as code build/release process _with signed, non-falsifiable provenance_
- Custom built, isolated build infrastructure, conforming to best practices such as those defined in the [DoD Reference Architecture](https://dodcio.defense.gov/Portals/0/Documents/Library/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20-%20CNCF%20Kubernetes%20w-DD1910_cleared_20211022.pdf), and [CNCF Best Practices](https://project.linuxfoundation.org/hubfs/CNCF_SSCP_v1.pdf)
- Custom built, isolated build infrastructure, conforming to best practices
- Verifiable SBOMs and dependency vulnerability reports

If we follow the SLSA level requirements using the enhancements introduced with Carbide Secured Registry (CSR), it currently puts us firmly at a SLSA level 2 (up from SLSA 0). However, the astute readers will recognize that with the current verbatim implementation of SLSA levels, level 3 and 4 are currently unobtainable due to requirements such as "accredited build platforms".

As stated earlier, the foundation for ultimately achieving SLSA 4 have been put in place to allow us to mature alongside software supply chain best practices, and standards. On that note, it's important to recognize that Carbide Secured Registry (CSR) is an ever evolving set of capabilities. Just as the standards and best practices around software supply chain security evolve, so will Carbide Secured Registry (CSR).
It's important to recognize that the Carbide Secured Registry (CSR) has an ever-evolving set of capabilities. As the standards and best practices around software supply chain security evolve, so will Carbide Secured Registry (CSR).