How I tackle Docker Hub rate-limiting policy with a policy engine Kyverno
In this article, I will be sharing how I got rid of the troublesome docker hub rate-limiting policy.
Problem
As you may know, Docker decided to limit image pull requests to the max of 100 per 6 hours from anonymous users. It may not affect many of the people, however, for large organizations like Hepsiburada, it became trouble in time.
Since there are limited numbers of public IPs provided for the company’s data centers, ErrImagePull events eventually increased in time.
How
First of all, since a docker hub pro account is not that expensive, we prefer to buy a pro account instead of pulling all the necessary images into our private image registry.
After we acquired the docker hub pro account details, we injected that image pull secret to the deployments pulling images from the docker hub.
However, I find this time-consuming and uncontrollable. Therefore, I need something to mutate the pod.
It can be done by writing a Kubernetes mutating webhook, but I decided to do this with something different.
There are some policy engines that are widely used for the validation of pod security. Kyverno is one of them, but it differs from OPA-gatekeeper by mutating and generating objects.
I am not going to compare these two policy engine in this article, you can check this article if you would like to see the differences.
ShowCase
Mutating and generating objects are the keywords for easily distributing the image pull secret in our case. I want to distribute the image pull secret to every newly created pod in any namespaces.
In order to do that, we are going to set 2 different policies, one is responsible to patch pods with the pull secret, and the other one is responsible to clone image pull secret to newly created namespaces.
In the following policy, we observe that it matches with pods with any container image , and patches them with our image pull secret.
Now we are able to inject our pull secret into any pod, however, we should have the “dockerhub” secret in every namespace.
Otherwise, even though pods are injected with the dockerhub secret by Kyverno, pods won't be able to find the secret in the namespace.
Luckily Kyverno is also able to generate objects, like secrets. So the following policy is going to clone the secret under the default namespace to any newly created namespace.
Conclusion
Both OPA-gatekeeper and Kyverno policy engines are great to enforce pod security policies. OPA-gatekeeper is very popular and flexible since it is programmable.
However, I found Kyerno easy to use, and useful with mutating and generating objects.
You can find some best practice policies under its own repository.
And you can find the usecase policies under this
