You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: v1kind: Secretmetadata:
name: default-registry-credentialstype: kubernetes.io/dockerconfigjsondata:
.dockerconfigjson: { // base64 "auths": {"*.example.com":{// will not work},"hello.example.com":{// this will work },}
The text was updated successfully, but these errors were encountered:
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
*.our-internal-repo.example
,no valid ImagePullSecret defined for something.our-internal-repo.example
and denies the image.When
something.our-internal-repo.example
,When
*.example.com
, but signature verification is not enabledsecret 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 forhello.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.
The text was updated successfully, but these errors were encountered: