Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sigstore support #808

Closed
7 tasks done
mudler opened this issue Oct 21, 2021 · 27 comments
Closed
7 tasks done

Sigstore support #808

mudler opened this issue Oct 21, 2021 · 27 comments
Assignees
Labels
kind/enhancement New feature or request

Comments

@mudler
Copy link
Contributor

mudler commented Oct 21, 2021

Is your feature request related to a problem? Please describe.
Currently we have the mtree plugin which allows to create manifests that can be used to match against installed packages. Although we want to provide a solution that can secure the full supply chain by also signing packages

Describe the solution you'd like
cosign support. This ideally should happen when:

  • we install packages with luet install when a user creates the derivative
  • we build packages, allowing to check with sigstore the source images before continuing to build. And push during repository creation/package building the signed artifacts
  • when we run manual upgrades with cos-upgrade. When we give either a container image as input or a set of packages
  • Document the vars used
  • Document on derivative pages how to use the verify so derivatives can verify that our images are signed properly

Note that all the followings could be provided in form of a plugin/extension, as we do with mtree, and the above functionalities should be optional for the user.

follow up

@mudler mudler added the kind/enhancement New feature or request label Oct 21, 2021
@mudler mudler self-assigned this Oct 21, 2021
@mudler mudler removed their assignment Oct 21, 2021
@Itxaka
Copy link
Contributor

Itxaka commented Oct 21, 2021

Is this option a user option, meaning derivatives would be the ones signing their artifacts and us just providing the method to do so, or this also includes signing our own artifacts?

In that case, who is gonna create the private key and where its gonna be stored? It would need to be available in github in order to sign the packages which is a big security risk already ... :/

@mudler
Copy link
Contributor Author

mudler commented Oct 21, 2021

Is this option a user option, meaning derivatives would be the ones signing their artifacts and us just providing the method to do so, or this also includes signing our own artifacts?

It does make sense also for us providing packages signed. Then it's user choice to verify or not the assets being downloaded

In that case, who is gonna create the private key and where its gonna be stored? It would need to be available in github in order to sign the packages which is a big security risk already ... :/

We can use github repository secrets to store the keys. Consider we did the same when we have added notary support too.

@Itxaka
Copy link
Contributor

Itxaka commented Oct 22, 2021

ummm

cosign doesnt seem to work on quay.io for now :/ sigstore/cosign#40

@Itxaka
Copy link
Contributor

Itxaka commented Oct 22, 2021

and it kind of not does 👍

$ cosign sign -key cosign.key quay.io/testitxaka/releases-opensuse:fedora
Enter password for private key: Pushing signature to: quay.io/testitxaka/releases-opensuse:sha256-9ff4c42c4178edb8aa5c07ad3e51c567f920e33f31e0a427702dfdc3af7ac921.sig
error: signing [quay.io/testitxaka/releases-opensuse:fedora]: uploading: PUT https://quay.io/v2/testitxaka/releases-opensuse/manifests/sha256-9ff4c42c4178edb8aa5c07ad3e51c567f920e33f31e0a427702dfdc3af7ac921.sig: MANIFEST_INVALID: manifest invalid; map[message:manifest schema version not supported]

@Itxaka
Copy link
Contributor

Itxaka commented Oct 22, 2021

we can use ttl.sh for testing (confirmed that it works) but until quay support is there, we wont be able to enable cosign. Should not take that long as version 3.6 of quay supports that, its just the hosted version needs to be updated.

@Itxaka Itxaka self-assigned this Oct 22, 2021
@Itxaka
Copy link
Contributor

Itxaka commented Oct 25, 2021

luet cosign plugin for luet created and published (as luet package) in here: https://github.com/rancher-sandbox/luet-cosign

@kkaempf
Copy link
Contributor

kkaempf commented Oct 25, 2021

luet cosign plugin for luet created and published (as luet package) in here: https://github.com/rancher-sandbox/luet-cosign

Github reports that the main branch was renamed to master 🙄

@Itxaka
Copy link
Contributor

Itxaka commented Oct 25, 2021

Github reports that the main branch was renamed to master roll_eyes

do we need everything to be on main?

Its just force of habit, all my custom local tooling is kind of hardcoded with master in mind and not flexible enough to change between different primary branches :/

I cna change it afterwards, no problem

@kkaempf
Copy link
Contributor

kkaempf commented Oct 25, 2021

I'd recommend to stick with github's new default main.

@Itxaka
Copy link
Contributor

Itxaka commented Oct 25, 2021

@kkaempf done!

@Itxaka
Copy link
Contributor

Itxaka commented Oct 26, 2021

In the case of building, I tested and the plugin signs everything correctly on push.
On the side of installing, same thing, the plugin checks for the signatures on package install.

So this is mainly done? The only problem is that quay is not supporting storing artifacts along so until that is in place, we cannot move forward with this.

There is an en var used for "legacy" repos (COSIGN_DOCKER_MEDIA_TYPES) but it doesnt seem to work as expected with quay:

[2021-10-26 09:42:03] Signing image: quay.io/testitxaka/releases-green:cos-img-recovery-0.7.1
[2021-10-26 09:42:08] Error while executing cosign: Pushing signature to: quay.io/testitxaka/releases-green:sha256-d36e1b8c9d5babbc85d9927ce686ec7ed8b51d187eba0634e4b31ec4fdba554b.sig
error: signing [quay.io/testitxaka/releases-green:cos-img-recovery-0.7.1]: uploading: PUT https://quay.io/v2/testitxaka/releases-green/manifests/sha256-d36e1b8c9d5babbc85d9927ce686ec7ed8b51d187eba0634e4b31ec4fdba554b.sig: MANIFEST_INVALID: manifest invalid; map[message:failed to parse manifest: manifest data does not match schema: u'application/vnd.dev.cosign.simplesigning.v1+json' is not one of ['application/vnd.docker.image.rootfs.diff.tar.gzip', 'application/vnd.docker.image.rootfs.foreign.diff.tar.gzip']

Failed validating 'enum' in schema['properties']['layers']['items']['properties']['mediaType']:
    {'description': 'The MIME type of the referenced object. This should generally be application/vnd.docker.image.rootfs.diff.tar.gzip. Layers of type application/vnd.docker.image.rootfs.foreign.diff.tar.gzip may be pulled from a remote location but they should never be pushed.',
     'enum': ['application/vnd.docker.image.rootfs.diff.tar.gzip',
              'application/vnd.docker.image.rootfs.foreign.diff.tar.gzip'],
     'type': 'string'}

On instance['layers'][0]['mediaType']:
    u'application/vnd.dev.cosign.simplesigning.v1+json']

Next step is to try to store them in a different repo, althougth this seems more convoluted as we have to propagate that signature repo all around (on build, on install, on upgrade, etc...) but looks like we can do that :)

@Itxaka
Copy link
Contributor

Itxaka commented Oct 26, 2021

Storing in a different repo works very nicely, so we can have our stuff in quay and the keys on dockerhub:

[2021-10-26 09:53:03] Signing image: quay.io/testitxaka/releases-green:cos-system-0.7.1.metadata.yaml
[2021-10-26 09:53:08] Cosign output: Pushing signature to: index.docker.io/itxaka/releases-green-signatures:sha256-48caa93df5a62b6c88c1d10f8555d457cd3003fb0b6235be32bd2a404e87db44.sig
[2021-10-26 09:53:08] Finished signing and pushing quay.io/testitxaka/releases-green:cos-system-0.7.1.metadata.yaml

@Itxaka
Copy link
Contributor

Itxaka commented Oct 26, 2021

We gonna have a metting with Flavio to know more about the whole cosign thingies and the stuff around it (rektor, keyless, etc..)

Then we gonna contact sec-team to know how to store private keys and such. So this is on hold for now.

@kkaempf kkaempf added the status/blocked Issue depends on another one label Oct 26, 2021
@mudler mudler removed the status/blocked Issue depends on another one label Oct 27, 2021
@Itxaka
Copy link
Contributor

Itxaka commented Oct 27, 2021

with #816 merged we now push signatures to raccos/releases-FLAVOR automatically on publish :D

Test:

# itxaka @ zeus in ~/projects/cos-toolkit on git:cosign o [19:54:00] 
$ export COSIGN_REPOSITORY=raccos/releases-green           

# itxaka @ zeus in ~/projects/cos-toolkit on git:cosign o [19:54:14] 
$ cosign verify quay.io/costoolkit/releases-green:repository.yaml                  
No TUF root installed, using embedded CA certificate.
No TUF root installed, using embedded rekor key

Verification for quay.io/costoolkit/releases-green:repository.yaml --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - Any certificates were verified against the Fulcio roots.

[{"critical":{"identity":{"docker-reference":"quay.io/costoolkit/releases-green"},"image":{"docker-manifest-digest":"sha256:bd5dbb36721de39bbb6a88812f3025d12fc6f67637363fbfa069e2540fe956ca"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEYCIQDS3SQnxj9ydPuMmFUv9XSltmtdUj2BkbAREnRQooy1igIhAJijj9ORjh4uxFUSYR0Bf3stAmo3UnFcJm7Vosxu5i1c","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoicmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI1MTBkYTg2OTgwMTgxNjE1YjA5ZmJjOTM3ZWJjNjcxMWRhNzgwZjFkZGM0MDU3ZjJiZTY3NTdjZWY0ZmIwNDEyIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJUUNnZ1Y2ajdGYmpBcVVuZFl2UHovWmM5OW1PZFFOZENEdGFWZ2F1NVN4UEF3SWdFUTlocTBhZ2dBOXZXTjlSL3NuK2Y3d3RrUHRnb3oxdkx5TXB4elV6ZmtRPSIsImZvcm1hdCI6Ing1MDkiLCJwdWJsaWNLZXkiOnsiY29udGVudCI6IkxTMHRMUzFDUlVkSlRpQkRSVkpVU1VaSlEwRlVSUzB0TFMwdENrMUpTVVJGVkVORFFYQmhaMEYzU1VKQlowbFVVR0p0ZVVwWmMwdDFSVzVIVWsxR09FWXhRMHRZZVhKbVEwUkJTMEpuWjNGb2EycFBVRkZSUkVGNlFYRUtUVkpWZDBWM1dVUldVVkZMUlhkNGVtRlhaSHBrUnpsNVdsTTFhMXBZV1hoRlZFRlFRbWRPVmtKQlRWUkRTRTV3V2pOT01HSXpTbXhOUWpSWVJGUkplQXBOVkVGNVRucEZNMDFxVVRGT1ZtOVlSRlJKZUUxVVFYbE9la1V6VGtSUk1VNUdiM2RCUkVKYVRVSk5SMEo1Y1VkVFRUUTVRV2RGUjBORGNVZFRUVFE1Q2tGM1JVaEJNRWxCUWt4UU0zUlZlVkkzU1VGVlpTOXZSSGxWYURSTk9VMTBXbXBoWlZoMmExYzRjM05aUkd3NGNEZDRNQ3RqUm1vMmNWSjJiRmd3WkRNS1lWQkdLMFpWVlRjM1QyMUROV2hwUjBGUVdrNUNSWFF5YzI5TVlsVllaV3BuWjBoRVRVbEpRblo2UVU5Q1owNVdTRkU0UWtGbU9FVkNRVTFEUWpSQmR3cEZkMWxFVmxJd2JFSkJkM2REWjFsSlMzZFpRa0pSVlVoQmQwMTNSRUZaUkZaU01GUkJVVWd2UWtGSmQwRkVRV1JDWjA1V1NGRTBSVVpuVVZWd1dFRmhDazl3WW00NFZUVkVRa1F4TW1zclpFdERiRkZGVWpSSmQwaDNXVVJXVWpCcVFrSm5kMFp2UVZWNVRWVmtRVVZIWVVwRGEzbFZVMVJ5UkdFMVN6ZFZiMGNLTUN0M2QyZFpNRWREUTNOSFFWRlZSa0ozUlVKQ1NVZEJUVWcwZDJaQldVbExkMWxDUWxGVlNFMUJTMGRqUjJnd1pFaEJOa3g1T1hkamJXd3lXVmhTYkFwWk1rVjBXVEk1ZFdSSFZuVmtRekF5VFVST2JWcFVaR3hPZVRCM1RVUkJkMHhVU1hsTmFtTjBXVzFaTTA1VE1XMU9SMWt4V2xSbmQxcEVTVFZPVkZGMUNtTXpVblpqYlVadVdsTTFibUl5T1c1aVIxWm9ZMGRzZWt4dFRuWmlVemxxV1ZSTk1sbFVSbXhQVkZsNVRrUkthVTlYV21wWmFrVXdUbWs1YWxsVE5Xb0tZMjVSZDJaM1dVUldVakJTUVZGSUwwSklWWGRqTkZwNFlVaFNNR05JVFRaTWVUbHVZVmhTYjJSWFNYVlpNamwwVEROS2FHSnRUbTlhV0VsMFl6SkdkUXBhUjBwMlpVTTVhbFF4VFhSa1J6bDJZa2QwY0dSRE9IVmFNbXd3WVVoV2FVd3paSFpqYlhSdFlrYzVNMk41T1dsa1YyeHpXa014ZEZsWVRqQmFXRWwwQ2xvelNteGFWelIwWlVSbk1saDZXVEJNYm14b1lsZDRRV050Vm0xamVUbHZXbGRHYTJONU9YUlpXRTR3V2xoSmQwOVJXVXRMZDFsQ1FrRkhSSFo2UVVJS1FWRlJjbUZJVWpCalNFMDJUSGs1TUdJeWRHeGlhVFZvV1ROU2NHSXlOWHBNYldSd1pFZG9NVmx1Vm5wYVdFcHFZakkxTUZwWE5UQk1iVTUyWWxSQlN3cENaMmR4YUd0cVQxQlJVVVJCZDA1d1FVUkNiVUZxUlVGeVV6UlROMjluTW5CaEsyNXNiVzVZVW5aNFNHbFVRbnBZYjNBMFNGaENNRFU1VG5GSE5VbzRDbGh6WTA5amVsSm5aMFZ4Y3l0WFYybEtWa2xIYW5aR2VVRnFSVUUzVGxSdFUxTXZPV0YzWkhKd01qVllhMmhWTVVScU5VaGhkMGxqTjFka1dGbExjbFFLVnpFdllqQkJLMDlPYmt0YUt6WjVTSHB4YkVGTFNpc3hOa2ROTlFvdExTMHRMVVZPUkNCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2c9PSJ9fX19","integratedTime":1635355496,"logIndex":802091,"logID":"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"}},"Subject":"https://github.com/rancher-sandbox/cOS-toolkit/.github/workflows/build-master-green-x86_64.yaml@refs/heads/master"}}]

@Itxaka
Copy link
Contributor

Itxaka commented Oct 27, 2021

welp, as a side effect we also verify when luet {install,repo update} if we set the plugin:

 itxaka @ zeus in ~/projects/cos-toolkit on git:cosign x [19:57:19] 
$ sudo -E luet --plugin luet-cosign repo update                                          
 Luet version 0.18.1-gc536aaa53c34dcc7a42d8bc64adce7ede0c1cd27 2021-10-20 1112 UTC
 
	Luet Copyright (C) 2019-2021 Ettore Di Giacinto
	This program comes with ABSOLUTELY NO WARRANTY.
	This is free software, and you are welcome to redistribute it
	under certain conditions.
	
 🍭 Enabled plugins:
 	➡  luet-cosign
 Downloading quay.io/costoolkit/releases-green:repository.yaml
|  Pulled: sha256:bd5dbb36721de39bbb6a88812f3025d12fc6f67637363fbfa069e2540fe956ca
 Size: 628B
 Downloading quay.io/costoolkit/releases-green:tree.tar.zst
|  Pulled: sha256:4eb1e85e1839d9998d9397d7dcc2d46a7cbaba942d2f0e7bc5018d43b8fcdd29
 Size: 38.8KiB
 Downloading quay.io/costoolkit/releases-green:repository.meta.yaml.tar.zst
\  Pulled: sha256:d3028b03b46f2af3e17dc8cba82e8f68d6afd0a7fc0aea7275c89fff549c16f0
 Size: 1.629MiB
\  🏠  Repository cOS revision: 131 - 2021-10-27 19:23:42 +0200 CEST
-  ℹ Repository: cos Priority: 1 Type: docker

Show nothing rigth? but the luet-cosign log show us that it was indeed verified:

[2021-10-27 19:57:46] Verifying image: quay.io/costoolkit/releases-green:repository.meta.yaml.tar.zst
[2021-10-27 19:57:46] Using experimental keyless verify!
[2021-10-27 19:57:50] Cosign output: No TUF root installed, using embedded CA certificate.
No TUF root installed, using embedded rekor key

Verification for quay.io/costoolkit/releases-green:repository.meta.yaml.tar.zst --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - Any certificates were verified against the Fulcio roots.

[{"critical":{"identity":{"docker-reference":"quay.io/costoolkit/releases-green"},"image":{"docker-manifest-digest":"sha256:d3028b03b46f2af3e17dc8cba82e8f68d6afd0a7fc0aea7275c89fff549c16f0"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEQCIHBLEvTP4NFjXTnsW0K9mb2oAQd6BabmZLbWjhIUs0/HAiBni+bVpHUFwSCLIAbVHo9HK7Dj9MnwQ7fsqkkt8C5ImQ==","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoicmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiIwNjhhZWMzZjBhNDg1OWM2Zjk2YzQ5NTE2MDBmM2ZhNjM5YWU0ZGQ4NTcxZGMyZjlhYjY3MzFlZmQ3ZjgxMzJiIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FUUNJQlhSSDNURnUvYjR3SXVDNEloeFVqUTh6bTU5TDJYdk5adGZDVk9rVlJVNEFpQldhNlA4L2Nad1l1TUVub2J1Q2tONFdCbUlFeUtZTEl6Wkx4Mm42ODg2Q2c9PSIsImZvcm1hdCI6Ing1MDkiLCJwdWJsaWNLZXkiOnsiY29udGVudCI6IkxTMHRMUzFDUlVkSlRpQkRSVkpVU1VaSlEwRlVSUzB0TFMwdENrMUpTVVJGUkVORFFYQmhaMEYzU1VKQlowbFVabkJaYkdsdU5XVlFSWFY0TjJ4RlNVbHNObkpMYm0xYWMwUkJTMEpuWjNGb2EycFBVRkZSUkVGNlFYRUtUVkpWZDBWM1dVUldVVkZMUlhkNGVtRlhaSHBrUnpsNVdsTTFhMXBZV1hoRlZFRlFRbWRPVmtKQlRWUkRTRTV3V2pOT01HSXpTbXhOUWpSWVJGUkplQXBOVkVGNVRucEZNMDFxVVRCT1JtOVlSRlJKZUUxVVFYbE9la1V6VGtSUk1FMHhiM2RCUkVKYVRVSk5SMEo1Y1VkVFRUUTVRV2RGUjBORGNVZFRUVFE1Q2tGM1JVaEJNRWxCUWt4eVpERk9RekphUWt3M0t6QXliRTl5V1VsdEwwbEdWM2hFT1doRFlWTllSemN3YTBGQllXOU5VMXBIVUdKNVYyMXpjMDF0V2pFS2FUbEtiWEZMWWxoak5XRkdZbnBYYmxOclVVNW1iakpxVVc5dEswb3lNbXBuWjBoRVRVbEpRblo2UVU5Q1owNVdTRkU0UWtGbU9FVkNRVTFEUWpSQmR3cEZkMWxFVmxJd2JFSkJkM2REWjFsSlMzZFpRa0pSVlVoQmQwMTNSRUZaUkZaU01GUkJVVWd2UWtGSmQwRkVRV1JDWjA1V1NGRTBSVVpuVVZWbGFqbDRDbEJzY1cxa1JXRlRRVmszUWt4SlEwcHpiMHB3VVZKcmQwaDNXVVJXVWpCcVFrSm5kMFp2UVZWNVRWVmtRVVZIWVVwRGEzbFZVMVJ5UkdFMVN6ZFZiMGNLTUN0M2QyZFpNRWREUTNOSFFWRlZSa0ozUlVKQ1NVZEJUVWcwZDJaQldVbExkMWxDUWxGVlNFMUJTMGRqUjJnd1pFaEJOa3g1T1hkamJXd3lXVmhTYkFwWk1rVjBXVEk1ZFdSSFZuVmtRekF5VFVST2JWcFVaR3hPZVRCM1RVUkJkMHhVU1hsTmFtTjBXVzFaTTA1VE1XMU9SMWt4V2xSbmQxcEVTVFZPVkZGMUNtTXpVblpqYlVadVdsTTFibUl5T1c1aVIxWm9ZMGRzZWt4dFRuWmlVemxxV1ZSTk1sbFVSbXhQVkZsNVRrUkthVTlYV21wWmFrVXdUbWs1YWxsVE5Xb0tZMjVSZDJaM1dVUldVakJTUVZGSUwwSklWWGRqTkZwNFlVaFNNR05JVFRaTWVUbHVZVmhTYjJSWFNYVlpNamwwVEROS2FHSnRUbTlhV0VsMFl6SkdkUXBhUjBwMlpVTTVhbFF4VFhSa1J6bDJZa2QwY0dSRE9IVmFNbXd3WVVoV2FVd3paSFpqYlhSdFlrYzVNMk41T1dsa1YyeHpXa014ZEZsWVRqQmFXRWwwQ2xvelNteGFWelIwWlVSbk1saDZXVEJNYm14b1lsZDRRV050Vm0xamVUbHZXbGRHYTJONU9YUlpXRTR3V2xoSmQwOVJXVXRMZDFsQ1FrRkhSSFo2UVVJS1FWRlJjbUZJVWpCalNFMDJUSGs1TUdJeWRHeGlhVFZvV1ROU2NHSXlOWHBNYldSd1pFZG9NVmx1Vm5wYVdFcHFZakkxTUZwWE5UQk1iVTUyWWxSQlN3cENaMmR4YUd0cVQxQlJVVVJCZDA1dlFVUkNiRUZxUlVGelQxRTBZbmx2UTFBd1FXcE5NemQxWkc1dFRXdFNXa2MyWkd0MGNWZFhVMDFxWjNCdVZGZDRDamt3TVM5WmJYRldiRlZJTkdVMllqaHpaSGxSYW1Rd1RVRnFRVEIzUTNKdVdFOUdjVGRyUjJONWRYTm5WSE4yZFROSmVEaFFSVVpDWjFSWVRGaGpkV2NLWVVKb2JHVnNhWFpuUTJGNmNXOTFRblJ6VWtWeWVrTjFjV3huUFFvdExTMHRMVVZPUkNCRFJWSlVTVVpKUTBGVVJTMHRMUzB0Q2c9PSJ9fX19","integratedTime":1635355485,"logIndex":802089,"logID":"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"}},"Subject":"https://github.com/rancher-sandbox/cOS-toolkit/.github/workflows/build-master-green-x86_64.yaml@refs/heads/master"}}]
[2021-10-27 19:57:50] Finished verifying quay.io/costoolkit/releases-green:repository.meta.yaml.tar.zst

@Itxaka
Copy link
Contributor

Itxaka commented Oct 28, 2021

With a patch for luet to print the plugin state on success the sign and verify is more clean to end users now.

@Itxaka
Copy link
Contributor

Itxaka commented Oct 28, 2021

@mudler can you clarify what we install packages with luet install when a user creates the derivative refers to exactly??

@mudler
Copy link
Contributor Author

mudler commented Oct 29, 2021

@mudler can you clarify what we install packages with luet install when a user creates the derivative refers to exactly??

We have to provide a way, when building the derivative to rely on cosign in order to secure the supply chain. For example, in the context of : https://rancher-sandbox.github.io/cos-toolkit-docs/docs/creating-derivatives/creating_bootable_images/#example how do I use sigstore to verify what I'm installing is signed?

@Itxaka
Copy link
Contributor

Itxaka commented Oct 29, 2021

isnt that already covered by the luet install using the plugin? like both cos-upgrade workflows and luet install workflow work in teh same way, so covering one, should cover the other?

Of course, docs-wise should cover both but implementation-wise should be covered by adding the verify to luet install.

@Itxaka Itxaka closed this as completed Oct 29, 2021
@Itxaka
Copy link
Contributor

Itxaka commented Oct 29, 2021

goddammit the color of close tricked me

@Itxaka Itxaka reopened this Oct 29, 2021
@mudler
Copy link
Contributor Author

mudler commented Oct 29, 2021

Yup implementation wise we should be good. We just have to refine how to consume that process when building a derivative (where do I take cosign from? and the plugin?). Maybe we can create a package with all the tooling, so we can advertize to copy them from that image manually

@Itxaka
Copy link
Contributor

Itxaka commented Oct 29, 2021

was thinking that maybe it should be part of the meta-minimal, both cosign and luet-cosing, so they are availabel out of the box?

So then its just setting the correct env vars to have the verify as part of the derivative build

@Itxaka
Copy link
Contributor

Itxaka commented Oct 29, 2021

or maybe create another meta, like meta/verify that would install both luet-mtree and luet-cosign so they are not forced upon derivatives as part of the cos-minimal, but can be easily installed.

@Itxaka
Copy link
Contributor

Itxaka commented Oct 29, 2021

with #823 merged we now by default verify on cos upgrade/deploy

@Itxaka
Copy link
Contributor

Itxaka commented Nov 2, 2021

Docs are provided. rancher-sandbox/cos-toolkit-docs#54
Meta package is provided. #833
Examples are updated. #833

@Itxaka
Copy link
Contributor

Itxaka commented Nov 4, 2021

Example of checking cos signatures in a derivative -> kairos-io/kairos#1

@Itxaka
Copy link
Contributor

Itxaka commented Nov 5, 2021

skip packages/repos is provided on https://github.com/rancher-sandbox/luet-cosign/releases/tag/v0.0.8

@Itxaka Itxaka closed this as completed Nov 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants