search

knative / serving

Kubernetes-based, scale-to-zero, request-driven compute
https://knative.dev/docs/serving/
Apache License 2.0
5.56k stars 1.16k forks source link

Add e2e test for creating a service with ImagePullSecrets #5934

Open taragu opened 4 years ago

taragu commented 4 years ago

/area API /area test-and-release

As part of #5866, we need to add an e2e test for creating a service with ImagePullSecrets after https://github.com/knative/serving/pull/5917 is merged.

/assign FYI @dgerd

knative-housekeeping-robot commented 4 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh by adding the comment /remove-lifecycle stale. Stale issues rot after an additional 30 days of inactivity and eventually close. If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

markusthoemmes commented 4 years ago

@taragu are you still working on this? If so, please remove the stale status.

taragu commented 4 years ago

/remove-lifecycle stale

taragu commented 4 years ago

I'm trying to construct the e2e test for creating a service with an image of a private registry. However, I'm running into a problem. It seems the only way to create a docker registry secret is with plain username and password (https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-docker-registry-em-), and we shouldn't have those information in any of our e2e tests or scripts. Does anyone know a workaround for this problem?

karlkfi commented 4 years ago

You can use a GCR _json_key in a docker registry secret, but it will also be in clear text (it gets base64 encoded). To make docker use a _json_key you use _json_key as the username and the keyfile json as the password. https://cloud.google.com/container-registry/docs/advanced-authentication#json-key

For an e2e test, tho, you'll probably want to deploy a local disposable private registry and generate credentials for it on-demand when you set up the test. https://docs.docker.com/registry/deploying/#native-basic-auth

taragu commented 4 years ago

@karlkfi thanks for your suggestion! /unassign I currently don't have the bandwidth for this. Anyone else please feel free to pick up this issue.

knative-housekeeping-robot commented 4 years ago

Issues go stale after 90 days of inactivity. Mark the issue as fresh by adding the comment /remove-lifecycle stale. Stale issues rot after an additional 30 days of inactivity and eventually close. If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

knative-housekeeping-robot commented 4 years ago

Stale issues rot after 30 days of inactivity. Mark the issue as fresh by adding the comment /remove-lifecycle rotten. Rotten issues close after an additional 30 days of inactivity. If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

mattmoor commented 4 years ago

/lifecycle frozen

mattmoor commented 4 years ago

They are ugly, but two options that work with GCR:

  1. Use _json_key and an IAM role that just has read access to a specific bucket.
  2. Use _json_key and an IAM role with NO access, but full from a bucket that's ACL'd with allAuthenticatedUsers (vs. allUsers).
evankanderson commented 3 years ago

One other thought (though this appears quite stale and maybe just needs to be killed?):

It might be possible to run a simple registry on-cluster using the https://hub.docker.com/_/registry image and a static private key?

/triage accepted

dprotaso commented 2 years ago

This type of e2e test would be useful since there are edge case that we need to exercise

ie. multiple secrets doesn't seem to work https://github.com/google/go-containerregistry/issues/723