Merge pull request #109 from CamrynCarter/IOC-disclaimer

remove outdated IOC disclaimer from CSR intro

docs/registry-docs/introduction.md

@@ -1,7 +1,11 @@
 # Introduction
 
-This page will walk through IOC expectations of the hardened registry and what exactly the hardened registry provides.
+This page will walk through benefits of the hardened registry and what exactly the hardened registry provides.
 
+<<<<<<< HEAD
+## What is the Carbide Secured Registry (CSR)?
+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.
+=======
 ## IOC Expectations
 As our product is still in the IOC phase, there are some expectations to level-set:
 
@@ -13,6 +17,7 @@ If you see issues and areas for improvement, please submit Github issues [here](
 
 ## 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.
+>>>>>>> parent of 324e51d (update registry docs introduction and SLSA)
 
 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.
 
@@ -29,6 +34,14 @@ The Carbide Secured Registry (CSR)  was designed from the ground up to build the
 - 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)
 - Verifiable SBOMs and dependency vulnerability reports
 
+<<<<<<< HEAD
+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).
+
+> **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 areas for improvement, please submit Github issues [here](https://github.com/rancherfederal/carbide-docs/issues).
+=======
 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).
+>>>>>>> parent of 324e51d (update registry docs introduction and SLSA)