DEV Community

Cover image for Using GitHub Container Registry with Kubernetes
Anton Sizikov
Anton Sizikov

Posted on • Edited on

Using GitHub Container Registry with Kubernetes

GitHub Container Registry was introduced on the 1st of September 2020. It's still in the Beta stage, so it's rather not recommended to use it in production. However, it offers us free private storage for our Docker images, at least until the end of the Beta period.

Private storage, free and unlimited download... looks like a good enough option for local development.

In this post, I'm going to configure my local Kubernetes cluster to pull images from my GitHub Container Registry.

Enable GitHub Container Registry

First things first. We need to enable GitHub Container Registry for our account (Process for your organization is almost the same).

Note GitHub Container Registry is in public beta state at the moment of writing, so it's subject to change. I recommend to follow the official documentation, it's more likely to be up to date.

Create Access Tokens

For now, Container Registry supports just one authorization option, which is Personal Access Token (PAT). I'm going to create two tokens here (note the scopes).

One token with read:packages scope will be used for my local Kubernetes cluster to perform pull actions. And another token I'll use to manage images in my registry (remember Authentication step from GitHub Packages configuration page?).

.dockerconfigjson

Once I have my PAT token created I can build an auth string using the following format:

username:123123adsfasdf123123 where username is my GitHub username and 123123adsfasdf123123 is the token with read:packages scope.

let's Base64 encode it first:



echo -n "username:123123adsfasdf123123" | base64
dXNlcm5hbWU6MTIzMTIzYWRzZmFzZGYxMjMxMjM=


Enter fullscreen mode Exit fullscreen mode

With this string I can compose a new .dockerconfigjson:



{
    "auths":
    {
        "ghcr.io":
            {
                "auth":"dXNlcm5hbWU6MTIzMTIzYWRzZmFzZGYxMjMxMjM="
            }
    }
}


Enter fullscreen mode Exit fullscreen mode

Which we can Base64 encode again:



echo -n  '{"auths":{"ghcr.io":{"auth":"dXNlcm5hbWU6MTIzMTIzYWRzZmFzZGYxMjMxMjM="}}}' | base64
eyJhdXRocyI6eyJnaGNyLmlvIjp7ImF1dGgiOiJkWE5sY201aGJXVTZNVEl6TVRJellXUnpabUZ6WkdZeE1qTXhNak09In19fQ==


Enter fullscreen mode Exit fullscreen mode

and store it at as dockerconfigjson.yaml file.

Note: base64 is not an encryption, so you should not commit this file! This is just for a demo.

And now we have prepared all the pieces, time to create a new secret



kubectl create -f dockerconfigjson.yaml
secret/dockerconfigjson-github-com created


Enter fullscreen mode Exit fullscreen mode

Which can be used later on when we schedule our pods:

And the final step is to check Pod Events (I'm using Lens Kubernetes IDE here).

Have fun, and enjoy it while it's free!

This is a cross post from my personal blog.

Top comments (4)

Collapse
 
elpddev profile image
Eyal Lapid

I have also succesfuly used the create secret kubectl cli command. It has the benefit of doing the transformation for you.

kubectl create secret docker-registry mysecretname --docker-server=https://ghcr.io --docker-username=mygithubusername --docker-password=mygithubreadtoken --docker-email=mygithubemail
Enter fullscreen mode Exit fullscreen mode
Collapse
 
sourcecodemage profile image
SourceCode Mage

I'll give this a try the next time a PAT expires. Do you know if the same command can be used to update the token to a new value after it expires? With this article's kubectl apply method, the renewal complained :

Warning: resource secrets/name is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
secret/name configured

But it did update the secret to the new value.

Collapse
 
sourcecodemage profile image
SourceCode Mage

Do you know if the same command can be used to update the token to a new value after it expires? Using your kubectl apply method, the renewal complained :

Warning: resource secrets/name is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
secret/name configured

But it did update the secret to the new value.

Collapse
 
hackus profile image
Mircea Sirghi

Man, you are the best!!!