pipeline integrity

119 views
Skip to first unread message

Javi D R

unread,
Feb 1, 2021, 12:08:05 PM2/1/21
to Grafeas Users
Hi

Apologies if the question is dumb, i just discovered this tool and i am really interested on it.

i would like to understand how grafeas ensures the integrity of a pipeline, it is, if my pipeline needs to pass steps A,B,C with an OK message, how will it make sure those messages are not tampered?

It is, i get how grafeas signs and store those messages, but, how does it prevent an attacker to call grafeas API directly and send a message simulating the step A has been completed, for example?

Im sure this is already explained but i am struggling to understand it

Thanks

Camilo Aguilar

unread,
Feb 1, 2021, 6:59:09 PM2/1/21
to Grafeas Users
Hey Javi, it is not a dumb question at all. Grafeas itself does not help you verify integrity of your software supply chain, that will be something for https://in-toto.io/. That said, you can still store InToto's metadata in Grafeas through its metadata type: https://github.com/grafeas/grafeas/blob/master/proto/v1beta1/intoto.proto  

Best, 
Camilo 

Balázs Gyurák

unread,
Feb 1, 2021, 8:48:50 PM2/1/21
to Grafeas Users
Hi,

Grafeas does not sign anything, it merely stores the signatures. You need to sign the payload yourself, then put the signature into Grafeas. Then, you need to give Kritis your public key, so it can verify that signature.

The reason integrity is ensured is that nobody knows your private key. You are responsible for keeping it a secret.

Hope this helps.
Balazs

Junyi Wang

unread,
Feb 7, 2021, 2:46:35 AM2/7/21
to Grafeas Users
Hi,

Based on Camilo and Balazs's threads, it seems that pipeline integrity could be achieved in two ways:
1. Using in-toto occurrences generated at each step of the software supply chain
2. Using other types of occurrences (e.g. Build, Package) with signature, generated at each step of the software supply chain.

In my opinion, Grafeas's generic types are able to store more metadata in an organized way compared with in-toto type and can do things in-toto won't be able to do (for example, blocking a deployment if the resource has CVE). But in-toto seems to be more mature and is designed to secure the software supply chain integrity. 

I am wondering, if the goals are to both achieve software supply chain integrity and to collect comprehensive metadata, what would be the recommended way? Should we solely use Grafeas's types (non-in-toto types) with signatures? Or Should we use both Grafeas's types and in-toto?

Thanks in advance.
Junyi

Aditya Sirish A Yelgundhalli

unread,
Feb 9, 2021, 11:09:20 AM2/9/21
to grafea...@googlegroups.com

Hi Junyi,

I'm part of the in-toto team and I just wanted to clarify a couple of things. in-toto was designed specifically to be agnostic when it came to these things -- it provides mechanisms for everything you've described and isn't locked into any one platform or tool.

In the scenario you described, in-toto can be paired with a vulnerability scanner of your choice to check if a resource has a CVE associated with it. This check would be written in as an inspection (https://github.com/in-toto/docs/blob/master/in-toto-spec.md#432-inspections), and would be performed during the verification workflow pre-deployment. This can happen in a Kubernetes admission controller, for instance.

Please feel free to ask me any questions. You can also direct any in-toto specific questions to in-toto...@googlegroups.com.

- Aditya

--
You received this message because you are subscribed to the Google Groups "Grafeas Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grafeas-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grafeas-users/3b5be111-1512-4eb0-addd-178bf0c57301n%40googlegroups.com.
OpenPGP_signature
Reply all
Reply to author
Forward
0 new messages