kubectl plugin for signing Kubernetes manifest YAML files with sigstore

Related tags

k8s-manifest-sigstore
Overview

k8s-manifest-sigstore

kubectl plugin for signing Kubernetes manifest YAML files with sigstore

⚠️ Still under developement, not ready for production use yet!

This kubectl subscommand plugin enables developer to sign k8s manifest yaml files and deployment teams to verify the authenticity of configurations. Not only is this possible for developers to sign and verify, but the integrity of deployed manifests can be confirmed on a k8s cluster.

intro

Installation

The plugin is a standalone executable file kubectl-sigstore.

To build this file, run the following.

git clone [email protected]:sigstore/k8s-manifest-sigstore.git
cd k8s-manifest-sigstore
make

You will find new file kubectl-sigstore.

To install the plugin, move this executable file to any location on your PATH.

Usage (bundle image on OCI registry)

Usage:
  kubectl sigstore [flags]
  kubectl sigstore [command]

Available Commands:
  apply-after-verify A command to apply Kubernetes YAML manifests only after verifying signature
  sign               A command to sign Kubernetes YAML manifests
  verify             A command to verify Kubernetes YAML manifests
  verify-resource    A command to verify Kubernetes manifests of resources on cluster

To use keyless signing, set export COSIGN_EXPERIMENTAL=1

Sign k8s yaml manifest files as bundle OCI image

K8s YAML files are bundled as image, and then pushed to OCI registory. Then, it is signed with cosign. A bundle image reference is added in metadata.annotations in manifest yaml by default.

kubectl sigstore sign -f foo.yaml --image bundle-bar:dev

Inserting annotation can be disabled by adding --annotation=false option. (If annotation is not added, --image option must be supplied when verifying signature.)

kubectl sigstore sign -f foo.yaml --image bundle-bar:dev --annotation=false

Verify a k8s yaml manifest file

kubectl sigstore verify -f foo.yaml

An image reference can be supplied with command option.

kubectl sigstore verify -f foo.yaml --image bundle-bar:dev

Create resource with a k8s yaml manifest file after verifying signature

kubectl sigstore apply-after-verify -f foo.yaml -n ns1

Verify a k8s yaml manifest of deployed resource with signature

kubectl sigstore verify-resource cm foo -n ns1

Commands

Usage:
  kubectl-sigstore sign -f <YAMLFILE> [-i <IMAGE>] [flags]

Flags:
  -a, --annotation              whether to update annotation and generate signed yaml file (default true)
  -f, --filename string         file name which will be signed (if dir, all YAMLs inside it will be signed)
  -h, --help                    help for sign
  -i, --image string            signed image name which bundles yaml files
  -k, --key string              path to your signing key (if empty, do key-less signing)
  -o, --output <input>.signed   output file name (if empty, use <input>.signed)
Usage:
  kubectl-sigstore verify -f <YAMLFILE> [-i <IMAGE>] [flags]

Flags:
  -f, --filename string   file name which will be signed (if dir, all YAMLs inside it will be signed)
  -h, --help              help for verify
  -i, --image string      signed image name which bundles yaml files
  -k, --key string        path to your signing key (if empty, do key-less signing)
Usage:
  kubectl-sigstore apply-after-verify -f <YAMLFILE> [-i <IMAGE>] [flags]

Flags:
  -f, --filename string   file name which will be signed (if dir, all YAMLs inside it will be signed)
  -h, --help              help for apply-after-verify
  -i, --image string      signed image name which bundles yaml files
  -k, --key string        path to your signing key (if empty, do key-less signing)
Usage:
  kubectl-sigstore verify-resource <options> [-i <IMAGE>] [flags]

opitons are same as "kubectl get"

Flags:
  -h, --help               help for verify-resource
  -i, --image string       signed image name which bundles yaml files
  -k, --key string         path to your signing key (if empty, do key-less signing)
  -n, --namespace string   namespace of specified resource

Security

Should you discover any security issues, please refer to sigstores security process

Info

k8s-manifest-sigstore is developed as part of the sigstore project.

We also use a slack channel! Click here for the invite link.

Issues
  • Add initial codes for kubectl signing plugins (#1)

    Add initial codes for kubectl signing plugins (#1)

    Signed-off-by: Yuji Watanabe [email protected] Co-authored-by: Hirokuni-Kitahara1 [email protected]

    This is PR to add initial codes to the repository.

    Issue => https://github.com/sigstore/k8s-manifest-sigstore/issues/3

    opened by yuji-watanabe-jp 2
  • image annotations added for signing/verifying process

    image annotations added for signing/verifying process

    This PR aims to add support for the signing and verifying process with annotations.

    Notes for the reviewer:

    • We have one breaking change in this PR, we change the flag annotation to annotation-metadata.

    Screen Shot 2021-07-08 at 23 18 50

    opened by developer-guy 2
  • bump up cosign version to v1.0.1

    bump up cosign version to v1.0.1

    Signed-off-by: Hirokuni-Kitahara1 [email protected]

    • bump up cosign version to v1.0.1
    • fix return code of each sub command
    opened by hirokuni-kitahara 1
  • support pattern based multiple resource specification in verify-resource

    support pattern based multiple resource specification in verify-resource

    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": { ... }
                },
                { ... },
                { ... }
            ]
    }
    
    enhancement 
    opened by hirokuni-kitahara 1
  • support pattern based multiple resource specification in verify-resource command

    support pattern based multiple resource specification in verify-resource command

    Signed-off-by: Hirokuni-Kitahara1 [email protected]

    This PR is to enable pattern based multi resource specification in kubectl sigstore verify-resource command. Users will be able to specify multiple resources on cluster as exactly same as kubectl get command.

    The corresponding issue: https://github.com/sigstore/k8s-manifest-sigstore/issues/5

    enhancement 
    opened by hirokuni-kitahara 1
  • Extend verify-resource sub-command

    Extend verify-resource sub-command

    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 -
    
    1. 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

    • [x] allow user to specify resources by file
    • [x] allow user to specify resources by bundle image
    • [x] support both keyless and keyed signing
    • [x] output format (pretty, json, yaml)
    • [x] 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)
    
    enhancement 
    opened by yuji-watanabe-jp 1
  • update content based manifest search

    update content based manifest search

    Signed-off-by: Hirokuni-Kitahara1 [email protected]

    • update content based manifest search method
    • update verify functions so that it could handle multiple candidate manifests
    • add a config option for the maximum number of candidates
    opened by hirokuni-kitahara 1
  • Pick a resource from N resources in manifest file robustly

    Pick a resource from N resources in manifest file robustly

    Signed-off-by: Hirokuni-Kitahara1 [email protected]

    update manifest detection mechanism to make it more robust against a YAML manifest which contains multiple resources.

    opened by hirokuni-kitahara 0
  • fix `sign` command to set oidc option

    fix `sign` command to set oidc option

    Signed-off-by: Hirokuni-Kitahara1 [email protected]

    • add oidc options as default value to support cosign v1.0.1 keyless signing
    opened by hirokuni-kitahara 0
  • update cosign `require` version in go.mod

    update cosign `require` version in go.mod

    Signed-off-by: Hirokuni-Kitahara1 [email protected]

    • update require in go.mod for avoiding too old versions
    opened by hirokuni-kitahara 0
  • Enable manifest build provenance

    Enable manifest build provenance

    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/[email protected]:c8273383d314bfb945f5a879559599990f055da92ee078bf0f960e006c8ebe8b   -             -
    the-deployment-75b9678fbb-7zlzv   the-container   docker.io/monopole/[email protected]:c8273383d314bfb945f5a879559599990f055da92ee078bf0f960e006c8ebe8b   -             -
    the-deployment-75b9678fbb-jqd55   the-container   docker.io/monopole/[email protected]: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
    
    enhancement 
    opened by yuji-watanabe-jp 1
Owner
sigstore
software supply chain security
sigstore
A kubectl plugin for finding decoded secret data with productive search flags.

kubectl-secret-data What is it? This is a kubectl plugin for finding decoded secret data. Since kubectl only outputs base64-encoded secrets, it makes

Keisuke Umegaki 9 Aug 27, 2021
the simplest testing framework for Kubernetes controller.

KET(Kind E2e Test framework) KET is the simplest testing framework for Kubernetes controller. KET is available as open source software, and we look fo

Riita 10 Sep 6, 2021
colorizes kubectl output

kubecolor Colorize your kubectl output get pods describe pods something wrong You can change color theme for light-backgrounded environment What's thi

Hidetatsu Yaginuma 517 Sep 7, 2021
The DataStax Kubernetes Operator for Apache Cassandra

Cass Operator The DataStax Kubernetes Operator for Apache Cassandra®. This repository replaces the old datastax/cass-operator for use-cases in the k8s

K8ssandra 40 Sep 10, 2021
Simplified network and services for edge applications

English | 简体中文 EdgeMesh Introduction EdgeMesh is a part of KubeEdge, and provides a simple network solution for the inter-communications between servi

KubeEdge 54 Sep 13, 2021
Managing your Kubernetes clusters (including public, private, edge, etc) as easily as visiting the Internet

Clusternet Managing Your Clusters (including public, private, hybrid, edge, etc) as easily as Visiting the Internet. Clusternet (Cluster Internet) is

Clusternet 218 Sep 8, 2021
A tool to dump and restore Prometheus data blocks.

promdump promdump dumps the head and persistent blocks of Prometheus. It supports filtering the persistent blocks by time range. Why This Tool When de

Ivan Sim 72 Aug 24, 2021
Kubernetes Operator for MySQL NDB Cluster.

MySQL NDB Operator The MySQL NDB Operator is a Kubernetes operator for managing a MySQL NDB Cluster setup inside a Kubernetes Cluster. This is in prev

MySQL 6 Sep 6, 2021
The Elastalert Operator is an implementation of a Kubernetes Operator, to easily integrate elastalert with gitops.

Elastalert Operator for Kubernetes The Elastalert Operator is an implementation of a Kubernetes Operator. Getting started Firstly, learn How to use el

null 12 Sep 4, 2021
General Pod Autoscaler(GPA) is a extension for K8s HPA, which can be used not only for serving, also for game.

Introduction General Pod Autoscaler(GPA) is a extension for K8s HPA, which can be used not only for serving, also for game. Features Compatible with a

Open Cloud-native Game-application Initiative 10 Aug 4, 2021
go-zero 从零到 k8s 部署

启动: 注意事项: dockerfile 文件配置了 LOCAL_HOST 环境变量 1、项目目录下执行 ./docker.sh 脚本生成 rpc服务docker镜像 ./docker.sh 2、docker-compose-db 创建 mysql redis etcd 容器 执行命令

liukai 47 Sep 6, 2021
Kubedd – Check migration issues of Kubernetes Objects while K8s upgrade

Kubedd – Check migration issues of Kubernetes Objects while K8s upgrade

Devtron Labs 10 Sep 10, 2021
An example of Kubernetes' Horizontal Pod Autoscaler using costume metrics.

Kubernetes Autoscaling Example In this project, I try to implement Horizontal Pod AutoscalerHPA provided by Kubernetes. The Horizontal Pod Autoscaler

Jaskeerat Singh Randhawa 4 Aug 28, 2021
Faster way to switch between kubeconfig files.

kubectl-cf Faster way to switch between kubeconfig files (not contexts). Usage of kubectl-cf: cf Select kubeconfig interactively cf [co

Who Lives in a Pineapple Under the Sea? 9 Jun 13, 2021
µTask is an automation engine that models and executes business processes declared in yaml. ✏️📋

µTask, the Lightweight Automation Engine µTask is an automation engine built for the cloud. It is: simple to operate: only a postgres DB is required s

OVHcloud 510 Sep 7, 2021
ArgoCD is widely used for enabling CD GitOps. ArgoCD internally builds manifest from source data in Git repository, and auto-sync it with target clusters.

ArgoCD Interlace ArgoCD is widely used for enabling CD GitOps. ArgoCD internally builds manifest from source data in Git repository, and auto-sync it

International Business Machines 14 Sep 1, 2021
A 'kubectl' plugin for interacting with Clusternet.

kubectl-clusternet A kubectl plugin for interacting with Clusternet. Installation Install With Krew kubectl-clusternet can be installed using Krew, pl

Clusternet 6 Aug 27, 2021
Kubernetes OS Server - Kubernetes Extension API server exposing OS configuration like sysctl via Kubernetes API

KOSS is a Extension API Server which exposes OS properties and functionality using Kubernetes API, so it can be accessed using e.g. kubectl. At the moment this is highly experimental and only managing sysctl is supported. To make things actually usable, you must run KOSS binary as root on the machine you will be managing.

Mateusz Gozdek 3 May 19, 2021
network-node-manager is a kubernetes controller that controls the network configuration of a node to resolve network issues of kubernetes.

Network Node Manager network-node-manager is a kubernetes controller that controls the network configuration of a node to resolve network issues of ku

kakao 87 Aug 17, 2021