chainguard-dev / terraform-provider-oci

Terraform provider to perform OCI image operations

Terraform Provider for OCI operations

🚨 This is a work in progress. 🚨

https://registry.terraform.io/providers/chainguard-dev/oci

This provider is intended to provide some behavior similar to crane.

Developing the Provider

To compile the provider, run go install. This will build the provider and put the provider binary in the $GOPATH/bin directory.

To generate or update documentation, run go generate.

In order to run the full suite of Acceptance tests, run:

TF_ACC=1 go test ./internal/provider/...

terraform-provider-oci's Issues

examples have leftover `crane_` prefix in dir names

`oci_exec_test` should have a documented starting directory

Ideally this would not vary based on the working directory the module happens to be invoked from, so I think ${path.module} is the best bet.

cc @imjasonh

crane_ref outputs

data "crane_ref" "test" {
  ref = "cgr.dev/chainguard/static:latest-glibc"
}

We can currently get its digest (crane_ref.test.digest) and full image ref (crane_ref.test.id). What else might be useful?

For images:

• crane_ref.test.layers, a list of objects with digest, size, mediaType
• crane_ref.test.files, a map of filepath -> object with contents, permissions (like local_file)

For indexes:

• crane_ref.test.manifests, a list of objects with digest, size, mediaType, platform
• crane_ref.test.images, a map of platform -> object, which is an image like above, which can give you layers, files, whatever

For any manifest:

• crane_ref.test.mediaType
• crane_ref.test.annotations, a map of string -> string

It probably only makes sense to populate files if we can do it lazily, which I'm not sure we can. We might be able to take as an input the filepaths to care about, and only populate those (and fail if they're not there):

data "crane_ref" "test" {
  ref = "cgr.dev/chainguard/static:latest-glibc"
  filepaths = ["/etc/passwd", "/lib/apk/db/installed"]
}

`oci_append` doesn't support multi-arch images

I noticed looking at the code that it uses remote.Image

oci_tag

resource "oci_tag" "tag" {
  digest_ref = oci_append.foo.image_ref
  tag        = "v1.2.3"
}

output "tagged" {
 value = oci_tag.tag.tagged_digest
}

Applies a tag to a previously built/fetched/signed/attested/verified/tested image by digest.

example for `oci_append` doesn't append anything

`oci_append` tries to write back to `base_image` which is weird and incorrect

oci_append.site: Creating...
╷
│ Error: Unable to push image
│ 
│   with oci_append.site,
│   on service.tf line 14, in resource "oci_append" "site":
│   14: resource "oci_append" "site" {
│ 
│ Unable to push image, got error: PUT https://gcr.io/v2/mattmoor-chainguard/apko-hugo-cloudrun/manifests/sha256:d983e9ebe396bdbb1a035aed87fa4e30551188393349ad54cbaaab4c5aaf388c: DIGEST_INVALID: Manifest digest
│ "sha256:95bd4706afe03ac83a251988698f0b87edc1f8ac47276c3077a6849c5b5ee719" does not match expected digest "sha256:d983e9ebe396bdbb1a035aed87fa4e30551188393349ad54cbaaab4c5aaf388c".

data source to validate image structure

Prior art: https://github.com/GoogleContainerTools/container-structure-test

Something like:

data "oci_ref" "image" {
  ref = "alpine"
}

data "oci_validate" "validate" {
  test {
    rule = (oci_ref.image.config.user = "nobody")
  }
  test {
    rule = (contains(oci_ref.image.config.env, "FOO=bar"))
  }
  test {
    file = {
      digest = oci_ref.image.id
      path = "/etc/passwd"
      contains = "nobody"
      not_contains = "my credit card number is:"
      permissions = "-rw-r--r--"
    }
  }
}

resource "google_cloud_run_service" "service" {
  image = oci_validate.validate.validated_ref
}

We can also consider command tests that effectively docker run <image> and inspect the result.

`oci_exec_test` should support a timeout

Maybe this can be done at the TF level too, but it'd be great to be able to specify at the oci provider level too (e.g. tests in this apply should have a default timeout of 30s).

cc @imjasonh

`oci_exec_test` should indicate a free port to the tests

Right now a lot of tests open ports and then hit them via curl or other things, but when run concurrently fixed ports cause failures.

Our CoreDNS tests work around this in bash, but it'd be great to have something more built in (and randomized so these searches don't also collide as @Dentrax and @developer-guy hit with our private images iirc):
https://github.com/chainguard-images/images/blob/dff0f86a3a70d0ab4c5f6508ea502b3048fb6e11/images/coredns/tests/02-nslookup-with-Corefile.sh#L13-L20

cc @imjasonh

`FREE_PORT` should be tracked at the provider level to avoid duplication

Here's an example where (I believe) we handed out the same free port to multiple concurrent processes:

If we track port's we've handed out at the provider level, then we can avoid duplication and have tests "return" then once the test is complete.

cc @imjasonh

`oci_append` doesn't set `Mode` so only `root` can access files

Here's an example file added with the provider shown via crane export and tar tvf: