Why does kritis-validation-hook add attestations in Reviewer.Review?

[dra...@mercari.com]

Hello, 

Now I'm working on making PoC of software supply chain for our cluster with Kritis.

I'm using kritis-validation-hook ( validation admission webhook ) to prevent docker image deployed without required attestations ( PGP signings ).

I'm not using gcbsigner because it's now only support Google Cloud Build with Google Cloud Source Repositories, instead I'm going to implement our custom signer based on gcbsigner.

However, it seems the webhook adds attestations in Reviewer.Review if the docker image doesn't have any violations.

https://github.com/grafeas/kritis/blob/master/pkg/kritis/review/review.go#L93-L95

I would expect if the docker image is NOT attested, the image should be rejected ( same as violations )

( It's like Binary Authorization )

So, could anyone please explain why Kritis doesn't reject non-attested images and adds attestations to them?

Probably this is ridiculous question... sorry if I completely misunderstood.

But it would be great if someone answer my question.

Thanks!

[Tejal Desai]

Ah!! That attestation indicates this image has passed the security policy at this time. We use this attestation to make sure we don't deny an image was already admitted in past.

I am out of office right now, but will give some detailed explanation once i am at work.

Thanks
Tejal

[Tejal Desai]

So, i created an issue here https://github.com/grafeas/kritis/issues/328

When Kritis gets a pod Admission Request, the Admission hook validates the container image against all the policies.

If the images passes all the check, we let the pod in. 

However, for Image Security Policy or ISP  (which i do understand is your use case), vulnerabilities keep getting discovered. 

An image which passed ISP today, might not pass tomorrow as a new vulnerability was discovered.

In this case, if deployment which uses the container image restarts or is scaled up, we do not want to deny this image.

We do not want to deny admission to an already admitted image.

There is no difference in the Admission Request when a new pod is created or its  re-started. Hence "Attestations" come in to picture.

Whenever Kritis admits a container image it attests it. Currently there is no expiry on the attestation and its valid forever.

In the admittance flow, if a container image as this "special" attestation, we allow it irrespective of whether it passes all the policy or not.

Does this all make sense?

Translating it your use case, say your tool singed an image and it was admitted in your cluster. In future, someone malicious entity deleted the attestation on the image and restarts all you applications. 

Kritis, will still allow all the containers in your cluster if you have Kritis Attestation Authority policy created as per here

Thanks

Tejal

[Ryuzo YAMAMOTO]

Hi, 

I intended to reply to kritis-users Google Group, but actually I replied to Tejal directly.

So I'm sending our discussion to the group.

Sorry about that.

On Thu, Feb 14, 2019 at 12:16 PM Tejal Desai <tejal...@google.com> wrote:

Yes, it makes sense. 

 

Will let you know when it's done.

Tejal

On Wed, Feb 13, 2019, 7:14 PM Ryuzo YAMAMOTO <dra...@mercari.com wrote:

Hi Tejal,

> Sounds good.  i will try to upload the branch tomorrow. 

Cool :)

> Before that, want to know more about your usecase. 

> Are you creating Image attestation for a verified image? 

Yes, correct.

There are many microservice teams in my company, and each team has their own namespace and different policies.

For example, a team needs to get their docker images approved by their manager and QA team to deploy the images to Kubernetes clusters.

So I'm now trying image attestation (PGP sign) for verified (approved) image.

Does that make sense?

Thank you!

On Thu, Feb 14, 2019 at 11:56 AM Tejal Desai <tejal...@google.com> wrote:

Sounds good.  i will try to upload the branch tomorrow. 

Before that, want to know more about your usecase. 

Are you creating Image attestation for a verified image? 

Thanks

Tejal 

On Wed, Feb 13, 2019 at 6:46 PM Ryuzo YAMAMOTO <dra...@mercari.com> wrote:

Hi Tejal,

Thank you for the quick response!

> Yes that is correct. I think i have a branch out with some changes for the same. I can check it in early next week.

>

> would you be able to work with that timeline?

Sounds good.

But my schedule of PoC is actually very tight ( end of this week... ) so it would be great if you push the branch so that I can see and try it.

Of course, I can work with that next week :)

Thank you!

On Thu, Feb 14, 2019 at 11:34 AM Tejal Desai <tejal...@google.com> wrote:

Yes that is correct. I think i have a branch out with some changes for the same. I can check it in early next week.

would you be able to work with that timeline?

Thanks

Tejal

On Wed, Feb 13, 2019 at 6:09 PM Ryuzo YAMAMOTO <dra...@mercari.com> wrote:

Hi Tejal,

Thank you for the reply!

Your explanation makes sense.

So I misunderstood that Kritis has a feature to check attestations which come from outside of Kritis (e.g. PGP sign attestation from our side), but it doesn't.

Current Kritis's policy is only for package vulnerability, but I need another policy to enforce PGP sign attestation from our side like Binary Authorization.

The reason why I'm now trying to use Kritis instead of Binary Authorization is that Binary Authorization only support "cluster-level" policies, I'd like to have "namespace-level" policies to enforce both PGP signing and vulnerability check.

Do you have any recommendations for my use case?

Now I'm thinking of extending the "ImageSecurityPolicy" for our use case, for example:

- Add new "Attestor" CRD to define user's attestor (outside Kritis) which has the followings:

  - Name

  - PGP public key

- Add "AttestationRequirements" to ImageSecurityPolicySpec which has "requireAttestationsBy" list (Attestor.Name) like Binary Authorization

  - https://cloud.google.com/binary-authorization/docs/policy-yaml-reference#requireattestationsby

- Extend the admission hook to validate the "AttestationRequirements" (PGP sign) and deny images if the validation fail.

What do you think?

Best

Ryuzo

-- 
You received this message because you are subscribed to the Google Groups "Kritis users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kritis-users...@googlegroups.com.
To post to this group, send email to kritis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kritis-users/f956ddd3-e6db-4797-9810-b5ded5163468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kritis users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kritis-users...@googlegroups.com.
To post to this group, send email to kritis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kritis-users/f956ddd3-e6db-4797-9810-b5ded5163468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tejal Desai]

to close the loop here, 

I pushed a branch for Ryuzo, with builder integrated. We will be contributing it next to the code.

Thanks

Tejal

---------- Forwarded message ---------
From: Ryuzo YAMAMOTO <dra...@mercari.com>
Date: Thu, Feb 14, 2019 at 7:25 PM
Subject: Re: Why does kritis-validation-hook add attestations in Reviewer.Review?
To: Tejal Desai <tejal...@google.com>

Hi Tejal,

Thank you for the reply.

I'm going to look into the commit today and let you know if I have any questions.

Best

Ryuzo

On Fri, Feb 15, 2019 at 7:00 AM Tejal Desai <tejal...@google.com> wrote:

Just sending this to you!

I have pushed a branch to my fork, https://github.com/tejal29/kritis/commits/add_builder_flow

Here is the commit that contains all of the diff

Please check it out and hopefully your prototype will be completed.

Feel free to reach out to me if you have any questions.

Thanks

Tejal

--