open-policy-agent / conftest

Write tests against structured configuration data using the Open Policy Agent Rego query language
https://conftest.dev
Other
2.87k stars 305 forks source link

Wrong created date when push to Google container registry #326

Closed lopeg closed 4 years ago

lopeg commented 4 years ago

When man uses conftest push to GCR, created date is "Jan 1, 1970" conftest Version: 0.17.1(Commit: 45177b4)

Expected current date

In fact image

Blokje5 commented 4 years ago

Thanks for reporting this issue @lopeg. I have been able to reproduce this issue: image

conftest push gcr.io/<project-id>/lennard-test:latest -p examples/kubernetes/policy

I'll have a look to see what is missing.

Blokje5 commented 4 years ago

I had a quick look into this issue: conftest push uses the ORAS library to push the Rego policies as OCI artifacts. My gut feeling is that the issue is that GCR does not support the OCI image format (It is not listed as one of the implementors).

However, after quickly glancing at the OCI image format spec and looking at the annotations section it seems we are also missing some of the required annotations on our manifest. I assume any OCI compliant registry uses the org.opencontainers.image.created annotation on the manifest to determine the created date. It should be easy enough to add that annotation to the OCI artifact that is pushed. Adding oras.WithConfigAnnotations(map[string]string{"org.opencontainers.image.created": "1985-04-12T23:20:50.52Z"} to the pushOpts should do the job. The question is how to fill the date. My feeling is we should use the last modified date of the rego files and use the date of the last file modified. @boranx @jpreese @garethr What is your opinion on this?

KeisukeYamashita commented 4 years ago

@Blokje5 Have you seen this document? It says GCR supports OCI image format. https://cloud.google.com/container-registry/docs/image-formats

But still, the annotation is missing as you mentioned.

Blokje5 commented 4 years ago

@KeisukeYamashita hmmm I wasn't aware. Thanks for pointing that out! I already tried locally adding the annotation to the bundles pushed to GCR, but still it displayed "Jan 1, 1970", which is why I assumed GCR did not support OCI formats. Then again, I should have expected GCR to deny the OCI artifact entirely if it was actually unsupported.

For now I have reported it as an issue on the GCR bug board. Hopefully that will provide some more insight into why the annotation is not displayed as the created date in GCR and how we can fix this issue.

KeisukeYamashita commented 4 years ago

@Blokje5 Thank you. I have been able to reproduce this issue too.

I also uploaded my OCI images with org.opencontainers.image.created annotation but still doesn't work.

Screen Shot 2020-06-27 at 17 42 00

For now I have reported it as an issue on the GCR bug board. Hopefully that will provide some more insight into why the annotation is not displayed as the created date in GCR and how we can fix this issue.

Thank you. Where did you report this issue? I couldn't find any issues in GCR IssueTracker 🤔

KeisukeYamashita commented 4 years ago

I tried to push to Azure Container Registry(ACR) but the creation date was not configurable. Whatever you configure as org.opencontainers.image.created, the container registry uses the timestamp of the pushed event.

Screen Shot 2020-06-28 at 13 40 13

Therefore, GCR default value(Jan 1, 1970) of Created timestamp is a bug...

The question is how to fill the date. My feeling is we should use the last modified date of the rego files and use the date of the last file modified. @boranx @jpreese @garethr What is your opinion on this?

IMO, we shouldn't configure create DateTime annotation, it should be configured by the cloud provider when developers push their image to the container registry

garethr commented 4 years ago

I've run into this issue with other tooling as well. Specifically with Bazel.

https://github.com/garethr/snykly/blob/master/BUILD#L27

There you need to specify the above stamp = True. I'm not sure what that does under the hood, but that's probably the answer to the conundrum.

jpreese commented 4 years ago

I just tested this as well, and this definitely seems like a GCR issue and should be fixed upstream.