Michał Matłoka — Senior Software Engineer

How to utilize ScalaTest commands better

Recently I’ve learned how to utilize ScalaTest commands better. Let’s say that you have a test where you want to run a specific failing case:

Usually, this can’t be done from IDE, but you can use a ScalaTest task testOnly with additional parameters passed after — . For example

testOnly *AnswerToLife* — -z “41”

will run only tests containing “41” in their description.

There are many other options you can use here, just take a look at ScalaTest docs.

Grzegorz Kocur — DevOps Engineer

How to install cert-manager on GKE private cluster

Today using https protocol to encrypt and ensure integrity of the data sent between the browser and the server is a must have. To use it one need a valid server SSL certificate, which can be purchased from various sellers or… obtained for free using LetsEncrypt — a great service which allows you to get a domain validated certificate with three months validity period. Renewing a certificate every 3 months can be painful, but c’mon, it’s FREE :).

Fortunately if you run the http server on Kubernetes, the process of requesting and renewing the certificate can be fully automated with cert-manager. TL;DR — it will constantly watch you ingress objects and if proper annotation is found — it will do all the dirty job for you.

Installing and using cert-manager is pretty straight forward, especially using helm — it needs only few steps which have to be performed once and the certificate problem is solved forever (check the documentation for details).

The current version of cert-manager uses the advanced technique to check if the created or updated Issuer, ClusterIssuer and Certificate resources submitted to the apiserver are syntactically valid. It’s a great idea which allows to catch all problems as early as possible, but also complicates things — there is a dedicated page for troubleshooting issues related to this functionality.

Recently I was fighting with exactly this issue: cent-manager installation went smoothly but when I was trying to add ClusterIssuer resource I got:

Error from server (InternalError): error when creating “./cluster-issuer.yaml”: Internal error occurred: failed calling webhook “clusterissuers.admission.certmanager.k8s.io”: the server is currently unable to handle the request

So I went through the troubleshooting page I mentioned above — but nothing helped. What was really funny (and annoying at the same time) I had a second cluster with exactly the same configuration where everything worked! But going deeper I realized the configuration was not the same: the second cluster was a Private Cluster (both clusters were running on GKE).

I started googling and it turned out the api server is not able to make a webhook call to webhook pod when using private cluster since the traffic is… firewalled!

As the solution one has to create a new firewall rule which allows a traffic from private master network to all worker nodes to TCP port 6443. The firewall rule in GCP uses the concept of “network tags” so one has to ensure all nodes are tagged correctly — it’s not easy and may require the pool recreation, but it’s another story :).

This issue can be also workaround by disabling webhooks completely — when using helm one has to set — set webhook.enabled=false

Please note — there are some open issues related to it, this one or this, so the port may be configurable in the future. It’s a very good idea to carefully read the changelog when upgrading cert-manager!

Adam Smolarek — Senior Software Engineer

How do HttpOnly cookies work

Do you know that there is such a thing like HttpOnly cookie? How do they work, and what is the difference between them and regular cookies?

Photo by Jade Wulfraat on Unsplash

First, you can set the cookie as HttpOnly by setting HttpOnly flag in the server response.

It will prevent all but one JavaScript API from accessing the cookie value. The one that will have access to it is Http API, which means that cookie will be added to consecutive requests to the server.

The advantage is that this way of handling cookies prevent successful Cross-Site Scripting attack from reading session stored in the cookie.

Another useful flag for cookies is Secure. This flag reduces the usage of cookie only to secure channels. What secure channel is? Browser defines it, but usually, it is a communication channel secured with SSL.

There is one issue with this, especially for development — localhost . It usually does not have SSL, and it is cumbersome to set up one properly. Because of that, when you set up your backend to return cookies as secure, they will suddenly stop working.

Which may lead to some frustrating debugging ;)

To sum up, HttpOnly and Secure are two cookie flags that you can use to secure cookies stored in the browser.