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
},
}
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.