Open zapman449 opened 3 years ago
I am also seeing this issue.
We are beginning our journey to implement binary authorization and are hoping to run Grafeas/Kritis standalone in our own cluster. To begin our learning, we are following the standalone docs.
The error @zapman449 indicated happens when running ./no_attestation.sh
. I am not a Go Developer or certificate expert, so I don't really understand the issue, but it seems like the Kritis Validation Hook doesn't like something about the key fingerprint.
When I run kubectl apply -f pod.yaml
at the end of no_attestation.sh
I expect a message back like Error from server: error when creating "pod.yaml": admission webhook "kritis-validation-hook.grafeas.io" denied the request: image gcr.io/kritis-tutorial/java-with-vulnz@sha256:<hash> is not attested
, as indicated in the documentation.
kubectl apply -f pod.yaml
results in Error from server (InternalError): error when creating "pod.yaml": Internal error occurred: failed calling webhook "kritis-validation-hook.grafeas.io": Post https://kritis-validation-hook.default.svc:443/?timeout=30s: EOF
When looking at the logs, I can see the same logs as OP of this issue.
and indicates there is some issue at https://github.com/grafeas/kritis/blob/master/pkg/kritis/secrets/pgpkey.go#L69
Follow https://github.com/grafeas/kritis/blob/master/docs/standalone/README.md
I'm having the same issue, and my working theory at the moment is that the interface on AttestationAuthority
has changed in code and in the instructions since the v0.2.2
release. The Helm chart used when you deploy the Kritis server though still references the v0.2.2
release, and it's not able to find the public key data due to the schema change on AttestationAuthority
, leading to some nil error pointers at runtime.
I'll be going through the same routine described in docs/standalone
to validate, but from the v0.2.2
tag.
Compare the interface of AttestationAuthority
at the v0.2.2
tag:
apiVersion: kritis.grafeas.io/v1beta1
kind: AttestationAuthority
metadata:
name: kritis-authority
namespace: default
spec:
noteReference: v1beta1/projects/standalone
privateKeySecretName: attestor
publicKeyData: $PUBLIC_KEY
to what it currently is on master
today:
apiVersion: kritis.grafeas.io/v1beta1
kind: AttestationAuthority
metadata:
name: kritis-authority
namespace: default
spec:
noteReference: v1beta1/projects/standalone
publicKeys:
- keyType: PGP
keyId: $KEY_FINGERPRINT
asciiArmoredPgpPublicKey: $PUBLIC_KEY
Working through the docs/standalone
README in the v0.2.2
branch I have gotten past step 2, but am now stuck in step 3 when running ./attestation_created.sh
. I'm getting the same issue described in #384
I'm able to get past the issue described in #384 now. The interface is nil
error I was getting was because I had encrypted the private key generated by gpg
with a password. As described in the PrivateKey type, it's PrivateKey
field is not available until calling Decrypt(passphrase []byte)
when encrypted like this (makes sense). Therefore the field was nil
.
Two approaches for getting past that:
docs/standalone/no_attestation.sh
. You can skip encrypting the keys by just pressing <Enter>
when prompted for a password. You'll get a warning when doing so.create_attestation.go
eventually expects to find that in the attestor
K8s Secret created when executing docs/standalone/no_attestation.sh
. That Secret is created by the following:kubectl create secret generic attestor --from-file=public=gpg.pub --from-file=private=gpg.priv
and can be updated to the following to capture the passphrase used if you encrypted the keys
kubectl create secret generic attestor --from-file=public=gpg.pub --from-file=private=gpg.priv --from-literal=passphrase=<password provided to gpg during creation>
After that I was also getting an error related to an invalid Note reference on the AttestationAuthority, and had to change the Note reference to projects/kritis
from v1beta1/projects/standalone
which is inside no_attestation.sh
. It now looks like the following:
apiVersion: kritis.grafeas.io/v1beta1
kind: AttestationAuthority
metadata:
name: kritis-authority
namespace: default
spec:
noteReference: projects/kritis
privateKeySecretName: attestor
publicKeyData: $PUBLIC_KEY
I'm now able to POST the occurrence and attestation signature to Grafeas using create_attestation.go
, but am now getting a Base64 decoding issue logged from the kritis-validation-hook
Pod when trying to kubectl apply -f pod.yaml
.
I0107 22:14:29.314411 1 admission.go:172] Starting admission review handler
version: v0.2.2
commit: bea073f2a2f299af94363dc399b7780fde8f2afc
I0107 22:14:29.315323 1 admission.go:137] handling pod java in...
I0107 22:14:29.315348 1 admission.go:258] Reviewing images for &Pod{ ... removed ... }
I0107 22:14:29.319934 1 admission.go:269] Found 1 Generic Attestation Policies
I0107 22:14:29.320693 1 review.go:68] Check if gcr.io/kritis-tutorial/java-with-vulnz@sha256:358687cfd3ec8e1dfeb2bf51b5110e4e16f6df71f64fba01986f720b2fcba68a has valid Attestations.
I0107 22:14:29.320725 1 review.go:71] Validating against GenericAttestationPolicy my-gap
I0107 22:14:29.371644 1 validating_transport.go:65] Cannot base64 decode signature: illegal base64 data at input byte 0
I0107 22:14:29.371673 1 strategy.go:49] Handling attestation via LoggingStrategy
I0107 22:14:29.371680 1 strategy.go:53] No valid attestations found for image gcr.io/kritis-tutorial/java-with-vulnz@sha256:358687cfd3ec8e1dfeb2bf51b5110e4e16f6df71f64fba01986f720b2fcba68a. Proceeding with next checks
I0107 22:14:29.371709 1 admission.go:319] Denying &Pod{ ... removed ... }
I0107 22:14:29.375552 1 admission.go:281] No ISPs found in namespace default
@frayer Thanks for the investigation, it looks like the bug might be due to schema change in AttestationAuthority. I'll look into a fix.
I got through that last Base64 decoding hurdle for at least v0.2.2 of Kritis. Kritis was expecting the PGP Signature to be Base64 encoded, so I made that change in create_attestation.go
before it writes the signature to K8s. After that I'm able to get the pass/fail behavior expected when attempting to apply the Pod.
All the changes I did can be viewed in this diff: https://github.com/grafeas/kritis/compare/v0.2.2...frayer:v0.2.2-standalone-install
I also updated to Helm 3 and Grafeas v0.1.6 along the way.
I'm not sure it's merge-worthy for a PR at this point since, as you mentioned, some of the Schemas may have evolved since the v0.2.2 release. It could help those trying to get v0.2.2 to work though.
I'd be happy to help with updating the docs in master
, but also wondering if there's a new versioned release (beta or otherwise) in the works where there would be an updated kritis-server
image to reference. That shows up in the docs when installing via Helm, which at the moment still points at gcr.io/kritis-project/kritis-server:v0.2.2
, leading to some of the mismatches I originally started with.
Are the new Schema types captured in gcr.io/kritis-project/kritis-server:latest
?
Expected Behavior
not panic
Actual Behavior
panic
Steps to Reproduce the Problem
not sure
Environment, commands
n/a
Additional info
Add any other context about the problem here (e.g. screenshots, links)