ITE-8 Proposal Draft: provide an in-toto-library - #29
Conversation
Signed-off-by: Furkan <furkan.turkal@trendyol.com> Co-authored-by: Erkan <erkan.zileli@trendyol.com> Co-authored-by: Batuhan <batuhan.apaydin@trendyol.com>
|
Cool! I love the idea of sharing sample policies somewhere. |
|
One thing that comes to mind is versioning the library, what this needs to be coordinated against, and how consumers can use a specified version. That would imply some distinction between examples and library for others to use programmatically |
|
Great idea! However, I'm not sure the name |
|
Agree that |
adityasaky
left a comment
There was a problem hiding this comment.
Thank you for submitting this draft!
| | link:https://github.com/Dentrax[Furkan], https://github.com/developer-guy[Batuhan], https://github.com/erkanzileli[Erkan] | ||
|
|
||
| | Status | ||
| | Active :smile: |
There was a problem hiding this comment.
| | Active :smile: | |
| | Draft |
| [[abstract]] | ||
| == Abstract | ||
|
|
||
| This ITE proposes creating a new repository called `in-toto-library` under `in-toto` organization. This would allow |
There was a problem hiding this comment.
I think in-toto-examples has some favour here. I personally like the sound of in-toto-policies to be quite clear about what we're talking about.
| . link:https://github.com/in-toto/in-toto-java/[in-toto-java] | ||
|
|
||
| Whereas in-toto provides end-to-end implementations using several programming languages, it requires responsibility | ||
| to maintain across different languages as you know. It _may_ take a lot of time to get specs up-to-date and requires constantly follow-up. |
There was a problem hiding this comment.
I'm not a 100% certain I follow how a library of policies tie into having multiple implementations. Could you elaborate on this point?
| link:https://www.accurics.com/resources/glossary/policy-as-code/[Policy as Code], is a general term that often refers to writing code in a high-level declarative language which describes policies. | ||
| The purpose of Policy as Code is to codify policy definitions in software, which allows for consistent, automated assessment of policy compliance in modern software development practices. | ||
|
|
||
| Increased security with reusable patterns and code snippets for creating additional policies. |
There was a problem hiding this comment.
I think it's useful to have "building blocks" for various types of policies for adopters to build on, but we should also make a note about ongoing maintenance / updates.
| Increased security with reusable patterns and code snippets for creating additional policies. | ||
| in-toto-library will allow the projects to move fast yet still keep information secure. By doing so, we can trust this library. | ||
|
|
||
| === Use Case 2: Providing Community-Owned Library of Policies |
There was a problem hiding this comment.
I think we can largely merge this with the previous use case...
|
|
||
| We can create a _source-of-truth_ by structuring information models and associated data schema such that every data element is mastered in only one place. | ||
|
|
||
| === Use Case 3: Verifying Attestations (OCI Registry) |
There was a problem hiding this comment.
Let's generalize the text in this section and then point to the examples in cosign etc.
| [[reasoning]] | ||
| == Reasoning | ||
|
|
||
| Policy as Code eliminates the need for manual implementation with regard to sustaining and maintaining projects in in-toto. |
There was a problem hiding this comment.
I think something to add here is that currently writing layouts (essentially policies for the current spec) is a semi-manual task at the moment, and this is feedback we've received from some users.
| It also removes human error, increases efficiency at the organizational level, allows for a large number of policies or changes, and protects systems from threats and disruptions. | ||
| It is also a bit easy to create and to extend policies for due to the presence of a large number of standard attestation specs. | ||
|
|
||
| [[security]] |
There was a problem hiding this comment.
I believe we should talk about a review process for new policies / updates, as well as regular maintenance. Outdated policy templates can lead to a false sense of the security adopters are getting by using in-toto.
| [[prototype-implementation]] | ||
| == Prototype Implementation | ||
|
|
||
| **Example Repository Structure** |
There was a problem hiding this comment.
Can we create a new repository using this format and point to it? We can move it to the in-toto namespace when this ITE is further along.
This ITE proposes creating a new repository called
in-toto-libraryunderin-totoorganization. This would allowstoring CUE and OPA policies under repository. This policies enforce correctness and truth of Attestation formats against pre-defined policies by running data format validating tools.
This is our first proposal on the in-toto community. 🎉 Sorry in advance for the any grammar errors. We are waiting your feedback! So we can improve the proposal according to your reviews. Still a lot to learn! 🤗
PTAL @dlorenc @verdverm
cc: @developer-guy @erkanzileli