grafeas / kritis Goto Github PK

Add an Admission Controller admits all pods
Add tests.

currently there are various kritis images used and deployed and it can be very difficult to identify which version/commit of kritis is running.

Right now the check for fully qualified images happens during ISP validation, but if there are no ISPs deployed then any image (even one that isn't fully qualified) can get through.

We can at least check for fully qualified images without an ISP while kritis is running.

There might be a case where users want to replace/regenerate the keys used for attesting valid pods. This might happen when a key is compromised or lost.
In such scenarios, we need to make sure, previously attested pods can still be verified by admission controller.
A kubectl plugin attest can fetch all the images which have attestation where in key id is secret name and re-attest them with the new secret key. It will delete any attestations for the same AttestationAuthority with older secret name in pgpKeyId.

kubectl plugin attest <AttestionAuthority Crd Name>

Need to design and implement integration testing for Kritis.
Deploying all objects i.e. CRDs, admission controller via helm.

1. Deploy a container which violates image security policy
2. Deploy a container which complies image security policy.

We should namespace all the labels and annotations with something like:

kritis.grafeas.io/

kritis pods log:

W0718 20:50:59.292609       1 client_config.go:552] Neither --kubeconfig nor --master was s
pecified.  Using the inClusterConfig.  This might not work.

everytime it is called. might be worth defining a --kubeconfig value to silence the error

Right now the cron job does not run off when we start the kritis-server.

Add it to main and kick it off.

• How to get logs
• How to remove the ValidatingWebhookConfiguration if kritis is down or failing

support prometheus varz, etc. endpoints in kritis to allow prometheus metric collection

Document the full schemas for the CRD types

Write Integration tests for Container Analysis Api

in #46 i forgot to add the config to deploy the ValidatingWebhook.

• Add simple Admission Controller to admit all pods
• Add Helm charts for deployment
• Read ImageSecurityPolicy Pods and verify container
• Add attestation verification Logic

This Admission Webhook will

1. watch for Image policy CRD.
2. use drydock api to fetch vuln occurrences (depends on #3 )
3. Implements the flow in DD shared internally

For type:pod that is deployed, kritis gives an error message at create time that an image is blocked and the explanation. for deployments, the pods are never created but the deployment succeeds, it might make sense to see if we can reject the deployment directly or do some better messaging here

this issue relates to adding isp integration test cases to kritis. currently it isn't clear how ISPs should work w/ kritis (one single isp vs multiple) and how repeated images, differing CVE tolerance levels, etc. should work. We can discuss here what test cases make sense and how kritis should act for each case.

• Create chart for Deploying Admission Webhok along with secrets.
• Create helm chart for deploying Kube ctl plugins
• Create a heml chart to deploy all RBAC roles. (#12)
• Configs for Default AttestationAuthority (Figure out a way to create gpg secrets on client's GKE cluster at install time and use them)
• All CRD configs.

Create a directory and add set up helm as defined in the tutorial.

Right now we are using container analysis alpha libs.
Please switch them to beta once they are available.

Add here.

Right now, we only log violated pods.
https://github.com/dlorenc/kritis/blob/5750fc4d74d1c6dd51d15f57002ad9a9b1bc26b0/pkg/kritis/violation/strategy.go#L31

• Add a Strategy to add labels and annotations
• Switch Default Logging Strategy to the newly added one.

We need to interact with Drydock to fetch notes and occurrences.

Currently, Kritis is having issues for the following integration test cases:

• submit no-digest (tag) image
• submit digest image
• submit no-digest (tag) whitelisted image
• submit digest whitelisted image

I believe this stems from two functionality issues:

• Currently Kritis times out when attempting to search CVEs (unsure if auth, query or API change related)
• Whitelisting images is not working as intended (unclear if this is related to above or is a separate issues in the functionality)

This is a Tracking issue for creating kritis release.
DRAFT already started by @tejal29
https://github.com/grafeas/kritis/releases/edit/untagged-25bedf8d6894d660f7d7

• Tar the kritis-charts along with install-script.
• Tar the kubectl resolve plugin along with its plugin.yaml

• Create test Project.
  Test project kritis-int-test created.

• Create test cluster

• Create a service account and add the keys to kokoro

1. This lib will take a ImageSecurityPolicy Spec
2. Apply all rules as below for a list of Vulz found.

Note: * Except listed in whitelistCVEs field.

Return true or false and the Reason.

Add tests for the same.

I looked at the certificate generated using the helm certgen plugin.

The

kubectl get csr tls-webhook-secret-cert -o jsonpath='{.status.certificate}' | base64 --decode > server.crt
openssl x509 -in server.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            38:33:1c:be:10:15:81:cc:85:aa:cd:a8:57:ad:63:04
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = 99461cd8-7b97-4511-9568-fa54f53bfb5f
        Validity
            Not Before: Jul 13 22:40:01 2018 GMT
            Not After : Jul 12 22:40:01 2023 GMT
        Subject: C = US, ST = Washington, L = Seattle, O = Suse, OU = CaaSP, CN = tls-webhook-secret-cert
        Subject Public Key Info:
         .... 

The certificate org, state and OU are the defaults defined in the plugin and not what we have here
https://github.com/grafeas/kritis/blob/master/kritis-charts/certs.yaml#L8

Debug this by running certgen command locally and see submit a cl upstream if required.

verify that if image has not been scanned or is not hosted on GCR, kritis has sane message to user

A list of stuff to add to get the webhook to work:

1. log: exiting because of error: log: cannot create log caused by glog, should be fixed by adding flag.Set("logtostderr", "true") in main.go
2. Adding secret to deployment yaml with container-analysis admin permissions so we can get CVEs
3. Parse project name from the image before creating container-analysis request
4. RBAC roles

Update the README.md to include:

• kritis install/delete information (certgen, container-analysis, pre-install, helm, cleanup, updating)
• kritis on GKE install guide
• kritis use example (crd, isp, attestation, etc)
• link to grafeas.io kritis whitepaper

When deploying a kritis in test cluster, the server was denied admission as the kritis-server container image was not whitelisted.
( I had a whitelist Image Spec Policy CRD deployed)
We should whitelist kritis-sever image either

• By shipping a default ImagePolicySpec with the kritis-server image in whitelist.
• Or hard code image in code.

Fix Background job invalid labels.

time="2018-07-19T20:42:08Z" level=error msg="handling violations: Pod \"kritis-validation-hook-54b9f7d9f7-cc5cz\" is invalid: metadata.labels: Invalid value: \"Image not resolved to digest.\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')"

• Write a lib to create Attestation Notes from Attestion Authority CRD.
• The GPG_SIGNATURE will be computed over the Red Hat’s Atomic Host attestation signature format. We will be using only the required fields as mentioned in BinAuth Signature Format

{
    "critical": {
        "identity": {
            "docker-reference": "gcr.io/tejaldesai-personal/image-whitelist-server"
        },
        "image": {
            "docker-manifest-digest": "2a9906e7e50e7eca27c6ac6d1d32ae16ea4da813c593d21fc20d1cc534182f4d"
        },
        "type": "atomic container signature"
    },

• Create an AttestationOccurence using the lib (#3)

• Write a function to verify Attestations.
  Rules:

  • In order to admit an image which has attestations but fails image policy, we need to make sure all attestation are valid.
  • In order to verify a signature, we need to follow the following steps.
  • Fetch the AttestationAuthority CRD from AttestationAuthority AttestationOccurence.NoteName
  • Make sure the AttestationOccurence.attestation.pgpSignedAttestation.pgpKeyId is same as defined in the AttestationAuthority.spec.privateKeySecretName. If they are not same, the user changed the key for this AttestationAuthority. Skip verifying this Occurrence. Look for other attestations with same key.
  • Decrypt the pgpSignature using the Kubernetes Secret and Verify we get the same Container name
    and Container digest from the atomic host attestation signature format.

We need to annotate pods running out of image security policy.
Implement this lib.
Note: Check with skaffold team on details.

currently the container analysis api can be enabled but if the image passed has not been process or vulnerability scanning has not been opted in, on deployment kritis returns

Error from server (InternalError): error when creating "integration/testdata/nginx/nginx-
no-digest.yaml": Internal error occurred: failed calling admission webhook "kritis-valida
tion-hook.grafeas.io": the server rejected our request for an unknown reason

Add CRD for image security Policy with validation and write tests for them.

Found this bug in the resolve-tags plugin trying to resolve the generic kaniko template
Given this file:

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=<path to Dockerfile>",
            "--bucket=<GCS bucket>",
            "--destination=<gcr.io/$PROJECT/$IMAGE:$TAG>"]
    volumeMounts:
      - name: kaniko-secret
        mountPath: /secret
    env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /secret/kaniko-secret.json
  restartPolicy: Never
  volumes:
    - name: kaniko-secret
      secret:
        secretName: kaniko-secret

The plugin printed:

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor@sha256:501056bf52f3a96f151ccbeb028715330d5d5aa6647e7572ce6c6c55f91ab374
    args:
    - null
    - null
    - null
    volumeMounts:
    - name: kaniko-secret
      mountPath: /secret
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /secret/kaniko-secret.json
  restartPolicy: Never
  volumes:
  - name: kaniko-secret
    secret:
      secretName: kaniko-secret

Parent Issue: #14

This is background go process which will use its own clock to sleep for an hour and check pods after every hour.

for kritis to operate on an image, the container-analysis api must be enabled, you must opt into vulnerability scanning on images, and the image you are deploying must have been scanned for kritis to properly process it

Change the field onlyFixesAvailable to onlyFixesNotAvailablein
https://github.com/grafeas/kritis/blob/af681d091bd423b3c684b309894e898bac8deac9/artifacts/examples/image-security-policy-example.yaml
The Spec mentions the same

• Support -f (multiple filenames)
• Support stdin
• Documentation (installation, usage, etc.)
• Integration tests

We can create another issue to track calling kubectl commands after.

currently when attempting to deploy a deployment like:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2 # tells deployment to run 2 pods matching the template
  template: # create pods using pod definition in this template
    metadata:
      # unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is
      # generated from the deployment name
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

kritis panics with

2018/07/18 19:42:31 Getting vulnz for nginx:1.7.9
2018/07/18 19:42:31 http2: panic serving 10.44.2.1:42594: runtime error: index out of range
goroutine 702 [running]:
net/http.(*http2serverConn).runHandler.func1(0xc42000d248, 0xc420117faf, 0xc420124e00)
        /usr/lib/google-golang/src/net/http/h2_bundle.go:5753 +0x190
panic(0x1093a60, 0x1a681c0)
        /usr/lib/google-golang/src/runtime/panic.go:502 +0x229
github.com/grafeas/kritis/pkg/kritis/metadata/containeranalysis.ContainerAnalysis.GetVulner
abilities(0xc420a5fd40, 0x1315400, 0xc420042028, 0xc4204281a0, 0xb, 0x1, 0x0, 0xb, 0xc42068
f640, 0xc42048f210)
        /usr/local/google/home/aprindle/kritis-go/src/github.com/grafeas/kritis/pkg/kritis/
metadata/containeranalysis/containeranalysis.go:59 +0x707

which is:
https://github.com/grafeas/kritis/blob/master/pkg/kritis/metadata/containeranalysis/containeranalysis.go#L59

tracking issue for kritis friction log notes, feel free to add anything

• adding action items from kritis friction log session:
• add commands for helm service-account perms on GKE
• do not hardcode linux for certgen plugin command, reference platform instead
• if helm has never been run, there is an issue w/ the $HELM_HOME/plugins dir
• try to reduce optional configuration (namespace, secret-name, etc) to reduce first time confustion
• refactor the getting started flow into quickstart=copy-command-get-something-running and using-kritis=more-in-depth
• remove requirements for git clone grafeas-kritis repo to use quickstart (ex: referencing yamls not by url, referencing install.sh from path, etc)

When we install kritis, we need to generate tls secrets.

We also need to do the same when user wants to deploy a new Attestation Authority.

One example of doing this:

1. Write a controller which will generate a pair of secrets.
   https://github.com/mittwald/kubernetes-secret-generator

2. Ask users to generate the secrets and then they would need to copy paste the secret.

This a tracking ticket for that.

currently the cloudbuild.yaml builds are failing and not creating the artifacts for each merge, i believe this is do the the docker image not having all the build deps required for kritis

The AttestationAuthority CRD will look like:
Definition

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
    name: attestation-authority
spec:
  group: kritis.github.com
  version: v1beta1
  scope: Namespaced
  names:
    plural: attestationauthorities
    singular: attestationauthority
    kind: AttestationAuthority

Fields.

apiVersion: kritis.github.com/v1beta1
kind: AttestationAuthority
metadata:
    name: qa-attestator
    namespace: qa 
spec:
    noteReference: v1alpha1/projects/image-signing
    privateKeySecretName: foo
    publicKeyData: dsfdasfdkla

The Controller will if kubernetes secret "foo" exists in namespace "qa".

TODO: What Controller can do if secret does not exist?.

1. The Controller can instead create gpg secrets and update the CRD with the public key?

Right now, when we install the Webhook without any image policies we see this error.

kubectl create -f exanple.yaml
Error:
 msg="fetching image security policies: error listing all image policy requirements: the server could not find the requested resource (get imagesecuritypolicies.kritis.grafeas.io)"

This error disappears when we deploy a image policy spec.
Lets not return false but just return true and log message "No Image policy CRD defined" or ship one by default

Formally document the steps required for a kritis user to update kritis on a cluster without breaking their image authorization.

The documentation can be in format of a code lab. Ping @tejal29 for link.

Add an empty directory structure and description.