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

Error no valid ImagePullSecret defined when host contains a wildcard #456

Open
pre opened this issue Mar 28, 2024 · 0 comments
Open

Error no valid ImagePullSecret defined when host contains a wildcard #456

pre opened this issue Mar 28, 2024 · 0 comments

Comments

@pre
Copy link
Contributor

pre commented Mar 28, 2024

What commit ID of Portieris did you experience the problem with?

v0.13.12

What went wrong?

When verification of image signatures is enabled, Portieris requires the workload define a valid image pull secret.

When

  • the image pull secret has a hostname with a wildcard *.our-internal-repo.example,
  • Portieris fails with no valid ImagePullSecret defined for something.our-internal-repo.example and denies the image.

When

  • the image pull secret has explicit something.our-internal-repo.example,
  • Portieris allows the image.

When

  • When the image pull secret has a hostname with a wildcard *.example.com, but signature verification is not enabled
  • Portieris allows the image but logs secret default-registry-credentials not defined for registry: hello.example.com

In our case, we provide each namespace with the same image pull secret with a wildcard host, because many images come from a different subdomain, even though the same credentials are allowed to the same service. Earlier we had cases where the subdomain could even not be known in advance.

While we can change our configuration and duplicate the credentials for each known registry subdomain (there are plenty), this behaviour took some time to figure out for a first time Portieris user.

What should have happened differently?

Portieris should understand that image pull credentials for *.world.com can be used for hello.world.com instead of failing with a somewhat misleading error message.

How can it be reproduced?

Create image pull credentials with a wildcard hostname. Enable Portieris trust configuration. See the request be denied.

apiVersion: v1
kind: Secret
metadata:
  name: default-registry-credentials
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: { // base64 
    "auths": {
      "*.example.com":{
        // will not work
      },
      "hello.example.com":{
        // this will work 
      },
    }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant