Description

In kubectl sigstore verify-resource subcommand (see #13), a user specifies the signed manifest and verifies if the resources deployed from the manifest are not changed from the signed state.

# build manifest
kustomize build ~/myapp > manifest.yaml

# sign manifest
kubectl sigstore sign manifest.yaml -i manifest-bundle:dev

# deploy application
kubectl apply -n myapp -f manifest.yaml

# verify application with signed manifest
kubectl sigstore verify-resource -n myapp -i manifest-bundle:dev

However, all the details below for building manifest are not in the generated manifest itself.

• which source files are used for building manifests.
• who run the build command
• what command is executed (for reproducibility)

The goal of this issue is to allow a user to track how the manifest is built.

This issue is the proposal to extend kubectl sigstore subcommands to allow the following features.

1. manifest-build sub command

• build manifest with template engine (e.g. kustomize)
• generate provenance data in intoto attestation format, which includes source materials (file hash or git url, commit, etc.) and built manifest
• push provenance data to Rekor

2. verify-resource sub command (extension to #13)

• verify-resource command allows us to verify if the current state of resources are not tampered (unchanged from the state defined in the signed k8s manifest file).
• New support of option --provenance option allows us to get provenance records of signed manifest for the k8s resources on cluster. The provenance explains how the manifest was built from the source files.

Implementation

• In manifest-build subcommand, all the source files used for building manifest are included in provenance.yaml file in in-toto format. kustomize template files could refer to the multiple git repositories during manifest build. For identifying all the source files, git repositories specified in kustomization.yaml files are traversed recursively.

• provenance record is available in Rekor with hash value for the manifest image. So, the verify-resource subcommand with --provenance option gets a provenance record for the manifest image used for verifying a resource on a cluster.

Usage scenario

Let's walk through the usage scenario below to explain how the proposed sub-commands (manifest-build, verify-resource) works. Sample app is borrowed from here.

.
├── README.md
├── configMap.yaml
├── deployment.yaml
├── kustomization.yaml
└── service.yaml

# Build manifest with provenance
$ kubectl sigstore manifest-build --kustomize -dir . --provenance provenace.json -i gcr.io/fifth-moment-319802/sample-manifest:dev > manifest.yaml
$ cat manifest.yaml | grep -E "^kind:"
kind: ConfigMap
kind: Service
kind: Deployment

# Sign manifest.yaml
$ cosign sign -key cosign.key gcr.io//sample-manifest:dev

# Upload provenance record to Rekor
$ rekor-cli upload --artifact ./provenance.json --public-key cosign.pub --type intoto --pki-format x509

# deploy app
$ kubectl apply -f manifest.yaml -n default

# verify resources on cluster
$ kubectl sigstore verify-resource -n default -i gcr.io/fifth-moment-319802/sample-manifest:dev -k cosign.pub --provenance

[SUMMARY]
TOTAL   VALID   INVALID
3       3       0

[MANIFESTS]
NAME                                            SIGNED   SIGNER   ATTESTATION   SBOM
gcr.io/fifth-moment-319802/sample-manifest:dev   true     N/A      found         -

[RESOURCES]
KIND         NAME             VALID
ConfigMap    the-map          true
Service      the-service      true
Deployment   the-deployment   true

[RESOURCES - PODS/CONTAINERS]
POD                               CONTAINER       IMAGE ID                                                                                           ATTESTATION   SBOM
the-deployment-75b9678fbb-5ztp7   the-container   docker.io/monopole/hello@sha256:c8273383d314bfb945f5a879559599990f055da92ee078bf0f960e006c8ebe8b   -             -
the-deployment-75b9678fbb-7zlzv   the-container   docker.io/monopole/hello@sha256:c8273383d314bfb945f5a879559599990f055da92ee078bf0f960e006c8ebe8b   -             -
the-deployment-75b9678fbb-jqd55   the-container   docker.io/monopole/hello@sha256:c8273383d314bfb945f5a879559599990f055da92ee078bf0f960e006c8ebe8b   -             -

[PROVENANCES - ATTESTATIONS]
ARTIFACT           gcr.io/fifth-moment-319802/sample-manifest:dev
MATERIALS   URI    kustomization.yaml
            HASH   7f9567086eb86f1778a2dee77d9c70d0399de59a9df5d5828547e20532279ec6
            URI    deployment.yaml
            HASH   d9501d2adfaa48d9f9f94fbac0ed24074fbf311cd7d16d1920bdac259e01ae20
            URI    service.yaml
            HASH   8793d287579a9ed1590c41c600c60fa634d205523b56860425f38102a00e12fb
            URI    configMap.yaml
            HASH   78d9149b6e67fdcdf395069f8497cab474c95033a5733beddda7858e6b9dbd24

"cosign.sigstore.dev/message" annotation is double gzipped:

$ kubectl sigstore sign -f configmap.yaml -k cosign.key
Enter password for private key: INFO[0001] 0D )2kQ????GoJ? ?\-nwY?g(RUsing payload from: /tmp/kubectl-sigstore-temp-dir3932530381/tmp-blob-file
INFO[0001] signed manifest generated at configmap.yaml.signed


$ cat configmap.yaml.signed
apiVersion: v1
data:
  game.properties: "enemy.types=aliens,monsters\nplayer.maximum-lives=5    \n"
  player_initial_lives: "3"
  ui_properties_file_name: user-interface.properties
  user-interface.properties: "color.good=purple\ncolor.bad=yellow\nallow.textmode=true
    \   \n"
kind: ConfigMap
metadata:
  annotations:
    cosign.sigstore.dev/message: H4sIAAAAAAAA/wCoAVf+H4sIAAAAAAAA/+yUT4ucTBDGPfspijm/Oq3t6LyCp1xyCeSU04BUxhop0v/objdjQr57cCbLJoEhy4ZssuDvUlIPWo9FP72N2m2PVjtPIbAZs4g+Gz/VxV5KUe3327d4fk04kA+52B6tOfG
o0eUzapU8EnHlVhWiKh+el34pKtEkcH7sgN9hChF9IsRzzPoHKRoYeehqIcpa7AqZFg1MS0M2/5elrGX6tx2u/El+mf+nRf4HllDXVXUz/7uyToqqqKQUshFVIsqiqKsEniWT9/lXduKBUT/1Oz//3AsBHb8jH9iaFu6KdMCIbQowoqbceevIR6bQwoYM6TmPs6P
QoWIy4T9tTYjkw8E4hTP5XOOZ9aQzxXcUuh0AwMFsUoCr3rPhyKj6i97CRi7axP3DoP7EinqDmlqYAvmMTSR/wuP3bpaXbmktbI5WWZ+P1g6dm7xTdDDX1nscupmUsh8PBpeSRzpHbQfqop8ovfj95vkDm6GFV5fD/wZdqini/XLQGBsxsjWhhc9fUoCr4WVp2UD
arnfmysrKC+BrAAAA//9dtdDzAAwAAAEAAP//Q7giKagBAAA=
    cosign.sigstore.dev/signature: MEQCICkya4hRxbvCucT8qxmB3bW916f8R9ZvSoUPngbflpnaAiAf1qT84B9cov2c6xAtvW649NZ3WcWZrhNnf7PcKOdS2w==
  name: game-demo


$ < configmap.yaml.signed yq -rc '.metadata.annotations."cosign.sigstore.dev/message"' | base64 -d | gunzip -c -
OL=)9:\r        T)n7cB{p&&!?lRRZE?mV;O!>^JQx~M893j<qV*~)*$p~a
}"s)yj!Z
LKC6eI~EPUu3NU"?%WvQ?;?
                       #?tm
0yG
   9?b2?mM83\3wlR?F.??zZM$nni-lVYSt0{G:Gm?(W])r5_Rei@?w
                                                       k]
                                                         


$ < configmap.yaml.signed yq -rc '.metadata.annotations."cosign.sigstore.dev/message"' | base64 -d | gunzip -c - | gunzip -c -
/tmp/compressing-tar-gz618330488/PaxHeaders.0/configmap.yaml0000000000000000000000000000004200000000000020407 xustar0017 gid=600260513
17 uid=637922363
/tmp/compressing-tar-gz618330488/configmap.yaml0000644000000000000000000000052614143303704021164 0ustar00user00000000000000apiVersion: v1
data:
  game.properties: "enemy.types=aliens,monsters\nplayer.maximum-lives=5    \n"
  player_initial_lives: "3"
  ui_properties_file_name: user-interface.properties
  user-interface.properties: "color.good=purple\ncolor.bad=yellow\nallow.textmode=true
    \   \n"
kind: ConfigMap
metadata:
  annotations: {}
  name: game-demo

Description

Would you be up for publishing binaries for ARM CPU architecture?

For example:

1. kubectl-sigstore-darwin-arm64
2. kubectl-sigstore-linux-arm64

Description

go version go1.17.2 darwin/amd64

...

go install github.com/sigstore/k8s-manifest-sigstore/cmd/kubectl-sigstore@latest

go: downloading github.com/sigstore/k8s-manifest-sigstore v0.1.0
go install: github.com/sigstore/k8s-manifest-sigstore/cmd/kubectl-sigstore@latest: github.com/sigstore/[email protected]: verifying module: checksum mismatch
	downloaded: h1:hEGzVLLm5wdwrxkThgo1VKEE6JH68OKz+gXKQN9eQl8=
	sum.golang.org: h1:NKVclDH/UFHBSYPVvgKbOwLLi8WTjvtiHOW8vY+E9kg=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

Description

I notice that when I try to verify the signature by using a public key, the verify sub-command still tries to verify the signature with a transparency log.

Steps to reproduce:

$ cosign generate-key-pair
$ kubectl run alpine --image=alpine \
    --restart='Never' \
    --dry-run=client -oyaml -- sh -c "sleep 600" > alpine.yaml
$ kubectl sigstore sign -f alpine.yaml \
      -k cosign.key \
      -i gcr.io/$(gcloud config get-value project)/hello-k8s-manifest-sigstore:v1 # succeed and alpine.yaml.signed file generated
$ kubectl sigstore verify -f alpine.yaml.signed -k cosign.pub
error occured during signature verification: error occured while verifying image `gcr.io/developerguy-311909/hello-k8s-manifest-sigstore:v1`; no matching signatures:
no certificate found on signature

cosign version: 0.8.3

Description

Add initial codes for kubectl signing plugins.

Question

This is blocking us from upgrading cosign.

Description
Users may consider specifying multiple resources for the command kubectl sigstore verify-resource by using pattern based argument as well as kubectl get command.

To support this kind of input argument, several features like the following will be added to verify-resource command as an enhancement.

Features

• support pattern based argument in verify-resource command (e.g. verify-resource cm -n sample-ns )
• handle some errors that occurred during multiple verification correctly
• known changes by system can be ignored properly (e.g. spec.clusterIPs[0] in Service is automatically added )
• print a full verification result for all specified resources
• enable to output the result as JSON/YAML
• the number of image pulls is minimized during single execution

Expected

$ kubectl sigstore verify-resource cm -n sample-ns -i some-manifest-image:latest
NAME               INSCOPE   VERIFIED   SIGNER                    ERROR                                       AGE
signed-cm-a        true      true       [email protected]                                               2h
signed-cm-b        true      true       [email protected]                                               3h
kube-root-ca.crt   true      false                                YAML manifest not found for this resource   17d

# enable JSON output
$ kubectl sigstore verify-resource cm -n sample-ns -i some-manifest-image:latest --output json
{
    "results":
        [
            {
                "object": { ... },
                "result": { ... },
                "error": { ... }
            },
            { ... },
            { ... }
        ]
}

Description
This issue is the proposal to extend verify-resource subcommand to allow the following features.

verify-resource subcommand allows user to inspect resources according to the sigstore signing.

• k8s manifest file is used to to deploy resources onto cluster by using kubectl. Many k8s apps are using this installation pattern today.
• k8s manifest file is uploaded as bundle image to OCI registry, and signed by using cosign sign.
• Later, user want to verify if the current state of resources are not tampered (unchanged from the state defined in the signed k8s manifest file).

In this verification, signed manifest is specified in metadata annotation of each resources, or command option explicitly.
If the resource is not changed from the signed manifest, it is reported as valid.

Two usage patterns of this sub-command.

1. A user specifies the resources by command options and checks if they are not changed from signed manifest. (signed manifest specified in metadata annotation is used in this case.)

kubectl sigstore verify-resource cm -n myapp

Resources can be specified by manifest.

kubectl get deploy -n myapp | kubectl sigstore verify-resource -f -

2. A user specifies the signed manifest and verifies if the resources deployed from the manifest is not changed from the signed state

# build manifest
kustomize build ~/myapp > manifest.yaml

# sign manifest
kubectl sigstore sign manifest.yaml -i manifest-bundle:dev

# deploy application
kubectl apply -n myapp -f manifest.yaml

# verify application with signed manifest
kubectl sigstore verify-resource -n myapp -i manifest-bundle:dev

Features to be extended

• allow user to specify resources by file
• allow user to specify resources by bundle image
• support both keyless and keyed signing
• output format (pretty, json, yaml)
• allow to specify configuration to skip check

Expected

Usage:
  kubectl sigstore verify-resource (RESOURCE/NAME | -f FILENAME | -i IMAGE) [options]

Flags:
  -c, --config string                  path to verification config YAML file (for advanced verification)
  -f, --filename string                manifest filename
  -i, --image string                   a comma-separated list of signed image names that contains YAML manifests
  -k, --key string                     path to your signing key (if empty, do key-less signing)
  -n, --namespace string               If present, the namespace scope for this CLI request
  -o, --output string                  output format string, either "json" or "yaml" (if empty, a result is shown as a table)

Description

Using the version command no longer shows accurate information. The output shown below is when running from the 0.4.3 release binary.

$ k sigstore version
{"Major":"","Minor":"","GitVersion":"(devel)","GitCommit":"unknown","GitTreeState":"unknown","BuildDate":"unknown","GoVersion":"go1.18.7","Compiler":"gc","Platform":"linux/amd64"}

Version

0.4.3

Description

Signing/verification through GitHub Actions is supported via cosign but there seem to be some difficulties with k8s-manifest-sigstore. Specifically, the subject either doesn't come through or the field isn't present. There are likely other incompatibilities.

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch main
Block force push not configured for branch main

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Description

I am getting an error when I am attempting to sign a YAML with the kubectl plugin.

Steps to reproduce the error

1. Created a cosign key pair using the generate command
2. installed kubectl signore plugin
3. Tried to sign a sample yaml using the command mentioned below.

Error :

kubectl sigstore sign -f simple_deploy.yaml -k cosign.key --tarball=no
Enter password for private key:
Using payload from: /var/folders/rc/bbc3zv_x51x0ly86x7899bdc0000gn/T/kubectl-sigstore-temp-dir2446365628/tmp-blob-file
FATA[0001] error occurred during signing: failed to sign the specified content: failed to sign a blob file: cosign.SignBlobCmd() returned an error: reading key: unsupported pem type: ENCRYPTED SIGSTORE PRIVATE KEY

Version

Cosign version
GitVersion: 2.0.1
GitCommit: 8faaee4d2b5f65678eb0831a8a3d5990a0271d3a
GitTreeState: "clean"
BuildDate: 2023-04-06T19:10:33Z
GoVersion: go1.20.3
Compiler: gc
Platform: darwin/amd64

kubectl version
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"darwin/amd64"}

sigstore version
kubectl sigstore version
{"Major":"0","Minor":"4","GitVersion":"v0.4.4","GitCommit":"unknown","GitTreeState":"unknown","BuildDate":"unknown","GoVersion":"go1.18.1","Compiler":"gc","Platform":"darwin/amd64"}

Question
Since Kyverno has built-in support to work with this project and verify manifests through writing a policy, would it be welcome to make mention of this in the project's README or elsewhere?

Description

Hi, I'm Joyce, working on behalf of Google and the Open Source Security Foundation to help essential open-source projects improve their supply-chain security.

I would like to suggest the adoption of SLSA Level 3. SLSA aims to improve open source security by identifying best practices regarding artifact building processes and source code management. It does this by aligning these best practices with levels from 0 to 4, which describe how many best practices the project is using.

Concerning the build process, SLSA highlights the importance of granting the integrity of binaries or artifacts, so that it's ensured that a binary's code really comes from the source code you’re relying on. This assurance relies on the usage of a provenance, which is verifiable and relatable to the artifact, describing where, when and how it was produced.

It is extremely easy to achieve the SLSA Level 1, just by configuring the Provenance Generation. To see the steps that are necessary to achieve the SLSA Levels, take a look at Getting Started at SLSA. And, considering that you are already using github actions to generate builds and following the criterias to SLSA Level 3, only by enabling the slsa provenance generation you would achieve the SLSA Level 3.

Would you be interested in a PR adding the provenance generation on your current build process? I've already created a fork to test if it would really be feasible to generate provenance using go-releaser, if you'd like to take a look at what I've done to enable it, it is in https://github.com/joycebrum/k8s-manifest-sigstore. Also an example of the artifact with provenance https://github.com/joycebrum/k8s-manifest-sigstore/actions/runs/3292435083.

I can also update the README to add:

• A brief paragraph to let your end-users know you generate provenance and guide them to verify it when downloading your artifacts.
• A SLSA 3 badge, to expose the current level of effort of the project around security and also to encourage new adopters of SLSA, to help raise the collective level of open source security.

Description
fix bugs of verify-resource command to check all the existing resources on cluster.
Also add output format option like --output json or --output yaml.

Expected usage

$ kubectl sigstore verify-resource cm -n sample-ns
NAME           VALID   SIGNER              SIG_REF                    DIFF
configmap-1    true    [email protected]   sample-manifest-1:latest   -
configmap-2    true    [email protected]   <embedded>                 -
configmap-3    false   [email protected]   sample-manigest-3:latest   {"key":"data.key1","value":...}
configmap-4    false 

$ kubectl sigstore verify-resource cm -n sample-ns --output json
{
    "results":
        [
            {
                "object": { ... },
                "result": { ... },
                "error": { ... }
            },
            { ... },
            { ... }
        ]
}

Description

Today, when a manifest is successfully verified, other than a success message nothing else is shown. Owing to the fact that there is no verbosity flag (and the K8S_MANIFEST_SIGSTORE_LOG_LEVEL=trace env var does not show this), that means it isn't possible to show anything else. For example, what was the subject, who was the issuer, any annotations, cert details, etc? There needs to be some way to access more of this information especially when using the public Rekor instance and keyless signing.

Description

I'm facing an issue with using k8s-manifest-sigstore to sign manifests in our Go project. k8s-manifest-sigstore is currently dependent on an older version of k8s.io/cli-runtime, v0.23.5, which is incompatible with the newer version v0.24+ that we're using in our project. This prevents us from using k8s-manifest-sigstore altogether.

Therefore, I would like to request that you update the k8s.io/cli-runtime dependency version to v0.24 or higher to support the projects using latest versions of k8s.io/cli-runtime. This would allow users like us to use k8s-manifest-sigstore without any conflicts.

Thank You.

Description

I am trying to use the keyless signing flow for signing a YAML file, and the command exits without providing a prompt to input the code:

I am using a windows / WSL2 environment and tried both windows and Linux:

On Ubuntu:

❯ kubectl-sigstore sign -f ~/kyverno.yaml

INFO[0001] Using payload from: /tmp/kubectl-sigstore-temp-dir2575530188/tmp-blob-file
Generating ephemeral keys...
Retrieving signed certificate...
error opening browser: exec: "xdg-open": executable file not found in $PATH
Go to the following link in a browser:

         https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=HVOHq8qZZUA3gcaeJbmhaWt-UTuLUOI_g6zd_ASzr7c&code_challenge_method=S256&nonce=21Zmm4YNIusln2axEqbJC8Xnroo&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&scope=openid+email&state=21Zmm4hHlnSDYzg8uqvNFQUSJyd
Enter verification code:
FATA[0001] error occurred during signing: failed to sign the specified content: failed to sign a blob file: cosign.SignBlobCmd() returned an error: getting key from Fulcio: retrieving cert: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_request","error_description":"Required param: code."}

On Windows:

λ kubectl-sigstore sign -f C:\tmp\kyverno\kyverno.yaml
time="2021-11-27T18:11:19-08:00" level=info msg="Enter the verification code WNDB-WQTN in your browser at: https://oauth2.sigstore.dev/auth/device?user_code=WNDB-WQTN\nCode will be valid for 300 seconds\nUsing payload from: C:\\Users\\jim\\AppData\\Local\\Temp\\kubectl-sigstore-temp-dir635928500\\tmp-blob-file\nGenerating ephemeral keys...\nRetrieving signed certificate...\nNon-interactive mode detected, using device flow.\n"
time="2021-11-27T18:11:19-08:00" level=fatal msg="error occurred during signing: failed to sign the specified content: failed to sign a blob file: cosign.SignBlobCmd() returned an error: getting key from Fulcio: retrieving cert: error obtaining token: expired_token"

Description

• refactor codes to make them more extensible
• fix some verification bugs
  　- fix verification bugs of some resource kinds that are automatically modified by k8s
  　- fix CRD dry run bugs