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.exampleand 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.comIn 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.comcan be used forhello.world.cominstead 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.