Kyverno Fixs

docs/integrating-scribe/admission-controller/kyverno.md

@@ -6,59 +6,101 @@ toc_min_heading_level: 2
 toc_max_heading_level: 5
 ---
 
-**[Kyverno](https://https://github.com/kyverno/kyverno)** is an open source policy engine designed for kubernetes. Valint integrates with the Kyverno **[verify-images](https://kyverno.io/docs/writing-policies/verify-images/)** rule; Kyverno can enforce policies requiring the use of signed images, and ```valint``` can be used to generate the required attestations that include the image signature.
+### **Introduction**
 
-### Sigstore Keyless admission
+[Kyverno](https://github.com/kyverno/kyverno) is an open-source policy engine designed for Kubernetes. It supports the **[verify-images](https://kyverno.io/docs/writing-policies/verify-images/)** rule, which enforces signed image usage policies. Valint integrates seamlessly with Kyverno, enabling users to generate required attestations, such as image signatures, to comply with these policies. 
 
-Use Kyverno keyless flow to verify the attestation (see also **[kyverno verify-images](https://kyverno.io/docs/writing-policies/verify-images/sigstore/#verifying-image-signatures)**)
+### Step 1: Evidence Generation in an OCI Store
 
-```yaml
-# Generate SLSA Provenance attestation
-valint slsa my_account/my_image:latest -o attest -f --oci
+To generate signed attestations using Valint, the OCI store must be enabled with the `--oci` flag.
+
+> Learn about alternative evidence storage options in our **[documentation](https://scribe-security.netlify.app/docs/integrating-scribe/other-evidence-stores)**.
+
+
+```bash
+# Generate Evidence attestation
+valint [bom,slsa] image -o attest --oci [--oci-repo repo]
+```
+
+- **Optional Flag**: `--oci-repo` specifies a central location for storing evidence.  
+- **Kyverno Integration**: When using `--oci-repo`, evidence is stored under `<evidence_repo>/container`. Configure the `repository` field in the Kyverno rule to reference this location.
+
+#### **Example**
+
+```bash
+valint my_account/my_image:latest -o attest --oci --oci-repo my_account/evidence --provenance
+```
+
+This command generates both SBOM and SLSA provenance and attaches them to the OCI store.
 
+---
+
+### Step 2 **Sanity check with Valint and OCI Store** [Optional]
+
+Use Valint to verify attestations or validate them against specific Kyverno policies.
+
+```bash
+# Verify Cyclonedx or Provenance attestation
+valint verify [image] -i [attest, attest-slsa] --oci [--oci-repo evidence_repo]
+```
 
+## Step 3 **Setting Kyverno `verifyImages` Rules**
+
+For detailed guidance on setting up Kyverno to verify image signatures, refer to the official **[Kyverno Verify Images documentation](https://kyverno.io/docs/writing-policies/verify-images/sigstore/#verifying-image-signatures)**.
+
+### **Sigstore Keyless Admission Example**
+
+If you’re using Sigstore for signing, here’s an example configuration:
+
+```yaml
 apiVersion: kyverno.io/v1
 kind: ClusterPolicy
 metadata:
- name: check-image-keyless
+  name: check-image-keyless
 spec:
- validationFailureAction: Enforce
- webhookTimeoutSeconds: 30
- rules:
-   - name: check-slsa-image-keyless
-     match:
-       any:
-       - resources:
-           kinds:
-             - Pod
-     verifyImages:
-     - imageReferences:
-       - "my_account/my_image*"
-       attestations:
-         - predicateType: https://slsa.dev/provenance/v1
-           attestors:
-           - entries:
-             - keyless:
-                 subject: name@example.com
-                 issuer: https://accounts.example.com
-                 rekor:
-                   url: https://rekor.sigstore.dev
+  validationFailureAction: Enforce
+  webhookTimeoutSeconds: 30
+  rules:
+    - name: check-slsa-image-keyless
+      match:
+        any:
+          - resources:
+              kinds:
+                - Pod
+      verifyImages:
+        - imageReferences:
+            - "my_account/my_image*"
+          # `repository` optional field expected in `[evidence-repo]/container` format
+          repository: "my_account/evidence/container"
+          attestations:
+            # - predicateType: https://cyclonedx.org/bom/v1.5
+            - predicateType: https://slsa.dev/provenance/v1
+              attestors:
+                - entries:
+                    - keyless:
+                        subject: name@example.com
+                        issuer: https://accounts.example.com
+                        rekor:
+                          url: https://rekor.sigstore.dev
 ```
 
-### Verifying using X509 Keys
+### **X509 Key-Based Verification**
 
-Use Kyverno X509 flow to verify the attestation (see also **[kyverno verify-images](https://kyverno.io/docs/writing-policies/verify-images/sigstore/#verifying-image-signatures)**)
+Generate SLSA and Cyclonedx attestations signed with X509 certificates using the following command:
 
-```yaml
-# Generate SLSA Provenance attestation
-valint slsa my_account/my_image:latest -o attest -f --oci \
+```bash
+valint [slsa,bom] my_account/my_image:latest -o attest -f --oci \
  --attest.default x509 \
  --cert cert.pem \
  --ca ca-chain.cert.pem \
  --key key.pem
 ```
 
-### Certificate example
+### **Certificate-Based Kyverno Example**
+
+Here’s an example policy for verifying X509-signed attestations:
+
+```yaml
 ```yaml
 apiVersion: kyverno.io/v1
 kind: ClusterPolicy
@@ -77,7 +119,10 @@ spec:
      verifyImages:
      - imageReferences:
        - "my_account/my_image*"
+       # `repository` optional field expected in `[evidence-repo]/container` format
+       repository: "my_account/evidence/container"
        attestations:
+        # - predicateType: https://cyclonedx.org/bom/v1.5
          - predicateType: https://slsa.dev/provenance/v1
            attestors:
            - entries:
@@ -154,8 +199,6 @@ spec:
                    -----END CERTIFICATE-----
 ```
 
-An explicit `cert` field is not required because Valint attaches certificate to its attestations.
-
 #### X509 Certificate Constraints​
 
 * Certificate must include a **[Subject Alternate Name](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6)** extension.

docs/integrating-scribe/ci-integrations/github/action-bom.md

@@ -169,15 +169,15 @@ To overcome the limitation install tool directly - **[installer](https://github.
 Containerized action can be used on Linux runners as following
 ```yaml
 - name: Generate cyclonedx json SBOM
-  uses: scribe-security/action-bom@v1.5.12
+  uses: scribe-security/action-bom@v1.5.14
   with:
     target: 'busybox:latest'
 ```
 
 Composite Action can be used on Linux or Windows runners as following
 ```yaml
 - name: Generate cyclonedx json SBOM
-  uses: scribe-security/action-bom-cli@v1.5.12
+  uses: scribe-security/action-bom-cli@v1.5.14
   with:
     target: 'hello-world:latest'
 ```

docs/integrating-scribe/ci-integrations/github/action-evidence.md

@@ -136,15 +136,15 @@ The `valint evidence` action is a versatile action designed to include various t
 Containerized action can be used on Linux runners as following
 ```yaml
 - name: Include evidence derived from a file
-  uses: scribe-security/action-evidence@v1.5.12
+  uses: scribe-security/action-evidence@v1.5.14
   with:
     target: some_file.json
 ```
 
 Composite Action can be used on Linux or Windows runners as following
 ```yaml
 - name: Include evidence derived from a file
-  uses: scribe-security/action-evidence-cli@v1.5.12
+  uses: scribe-security/action-evidence-cli@v1.5.14
   with:
     target: some_file.json
 ```

docs/integrating-scribe/ci-integrations/github/action-slsa.md

@@ -155,15 +155,15 @@ To overcome the limitation install tool directly - [installer](https://github.co
 Containerized action can be used on Linux runners as following
 ```yaml
 - name: Generate SLSA provenance
-  uses: scribe-security/action-slsa@v1.5.12
+  uses: scribe-security/action-slsa@v1.5.14
   with:
     target: 'busybox:latest'
 ```
 
 Composite Action can be used on Linux or Windows runners as following
 ```yaml
 - name: Generate cyclonedx json SBOM
-  uses: scribe-security/action-slsa-cli@v1.5.12
+  uses: scribe-security/action-slsa-cli@v1.5.14
   with:
     target: 'hello-world:latest'
 ```

docs/integrating-scribe/ci-integrations/github/action-verify.md

@@ -163,15 +163,15 @@ Containerized action can be used on Linux runners as following
 ```yaml
 - name: valint verify
   id: valint_verify
-  uses: scribe-security/action-verify@v1.5.12
+  uses: scribe-security/action-verify@v1.5.14
   with:
       target: 'busybox:latest'
 ```
 
 Composite Action can be used on Linux or Windows runners as following
 ```yaml
 - name: Generate cyclonedx json SBOM
-  uses: scribe-security/action-verify-cli@v1.5.12
+  uses: scribe-security/action-verify-cli@v1.5.14
   with:
     target: 'hello-world:latest'
 ```

docs/integrating-scribe/other-evidence-stores.md

@@ -6,60 +6,81 @@ toc_min_heading_level: 2
 toc_max_heading_level: 5
 ---
 
-### OCI Evidence store
+### OCI Evidence Store
 
-In standalone deployments or other cases when you don’t want to connect your SDLC with Scribe Hub, you can use an OCI registry to store and retrieve evidence. This allows you to store evidence from your CI pipeline and retrieve it at the point of admission control into your Kubernetes cluster.
+In standalone deployments or scenarios where connecting your SDLC with Scribe Hub is not desired, you can leverage an OCI registry to store and retrieve evidence. This setup enables evidence storage from your CI pipeline and retrieval during admission control in a Kubernetes cluster.
 
 #### Flags
 
-* `--oci` Enable OCI store
-* `--oci-repo` Evidence store location
-`oci-repo` setting indicates the location in a registry under which the evidence is stored. It must be a dedicated location in an OCI registry. for example, ```scribesecuriy.jfrog.io/my_docker-registry/evidence```.
+* `--oci`: Enables the use of an OCI evidence store.
+* `--oci-repo`: Specifies the registry location for evidence storage.  
+  The `oci-repo` value defines the dedicated location within an OCI registry for storing evidence. For example: `scribesecurity.jfrog.io/my_docker-registry/evidence`.
 
-:::note
-Docker Hub does not support the subpath format, `oci-repo` should be set to your Docker hub Username.
+:::note  
+Docker Hub does not support subpath formats. When using Docker Hub, set `oci-repo` to your Docker Hub username.  
 :::
 
-Some registries such as Artifactory allow multi-layer format for repo names such as,
-```my_org.jfrog.io/policies/attestations```
+Some registries, such as Artifactory, support multi-layer repository names. For example:  
+`my_org.jfrog.io/policies/attestations`
 
-#### Before you begin​
-Evidence can be stored in any accessible registry.
-* Write access is required for upload (generate).
-* Read access is required for download (verify).
-You must first log in with the required access privileges to your registry before calling Valint. For example, using the `docker login` command.
+#### Evidence Storage
+
+Evidence is stored in the specified `oci-repo` location with suffixes based on the asset type:
+- **Image assets**: `container`
+- **Git assets**: `git`
+- **Directory assets**: `directory`
+- **Generic assets**: `generic`
+
+If no `oci-repo` is provided, evidence will be stored alongside the image. For additional details, see [Cosign Signed Container Images](https://blog.sigstore.dev/cosign-signed-container-images-c1016862618/).
+
+#### Before You Begin  
+
+Ensure the registry you plan to use is accessible:
+* **Write access** is required to upload (generate) evidence.
+* **Read access** is required to download (verify) evidence.
+
+You must log in to your registry with appropriate privileges before executing Valint commands. For example, you can use the `docker login` command.
 
 #### Usage
-```
-# Generating evidence, storing on [my_repo] OCI repo.
-valint slsa [target] -o [attest, statement] --oci --oci-repo=[my_repo]
 
-# Verifying evidence, pulling attestation from [my_repo] OCI repo.
-valint verify [target] -i [attest-slsa, statement-slsa] --oci --oci-repo=[my_repo]
-```
-For image targets only you may attach the evidence in the same repo as the image.
+```bash
+# Generating evidence and storing it in the [my_repo] OCI repository
+valint [bom, slsa] [target] -o [attest, statement] --oci --oci-repo=[my_repo]
+
+# Verifying evidence by retrieving it from the [my_repo] OCI repository
+valint verify [target] -i [attest, attest-slsa, attest-generic, statement-slsa] --oci --oci-repo=[my_repo]
 ```
-valint slsa [image] -o [attest, statement] --oci
+
+For image targets, you can store evidence directly in the same repository as the image:
+
+```bash
+valint [bom, slsa] [image] -o [attest, statement] --oci
 
 valint verify [image] -i [attest-slsa, statement-slsa] --oci
 ```
-### Cache Evidence store
-Valint supports both storage and verification flows for attestations and statement objects utilizing a local directory as an evidence store. This is the simplest form and is mainly used to cache previous evidence creation
+
+---
+
+### Cache Evidence Store
+
+Valint also supports using a local directory as an evidence store for both generating and verifying attestations and statements. This is a simple option, often used for caching previously created evidence.
 
 #### Flags
-* `--cache-enable` 
-* `--output-directory` 
-* `--force`
-By default, this cache store is enabled. To disable use `--cache-enable=false`.
+
+* `--cache-enable`: Enables or disables the cache store (default is enabled).
+* `--output-directory`: Specifies the local directory for storing evidence.
+* `--force`: Forces overwriting existing evidence.
+
+To disable the cache store, use `--cache-enable=false`.
 
 #### Usage
-```
-# Generating evidence, storing on [my_dir] local directory.
-valint slsa [target] -o [attest, statement] --output-directory=[my_dir]
 
-# Verifying evidence, pulling attestation from [my_dir] local directory.
+```bash
+# Generating evidence and storing it in the [my_dir] local directory
+valint [bom, slsa] [target] -o [attest, statement] --output-directory=[my_dir]
+
+# Verifying evidence by retrieving it from the [my_dir] local directory
 valint verify [target] -i [attest-slsa, statement-slsa] --output-directory=[my_dir]
 ```
-By default, the evidence is written to `~/.cache/valint/`, use `--output-file`, `-d`, or `--output-directory` to customize the evidence output location. 
-
 
+By default, evidence is stored in `~/.cache/valint/`. You can customize the output location using options like `--output-file`, `-d`, or `--output-directory`.