Red Flag #5, #6, #7, certificates

The terraform apply completing was the opportunity to escape from the nested block conversation above. With the GCP Kubernetes UI in the background, I mentioned we would have to wait for the certmanager processes to get us some certificates.

“Just visit it now”, the interviewer demanded. Since HSTS was used I could not visit this page without a certificate error you cannot bypass in Chrome. I tried explaining this. “Just push proceed” was the response. The HSTS error page has no proceed button when it is displayed. This is exactly what happened because we did not wait for the certificates to finish. There is no proceed.

“You can proceed. Just proceed” was the persistent instructions. I insisted we wait while staring at a window with no proceed button and an HSTS error. It wouldn’t take that long for the certmanager process to complete. If he really wanted me to, I could probably get around the certificate related HSTS restriction with Firefox since I had not visited the HSTS enabled site with that browser. The interviewers (multiple, at this point) argued Chrome would work fine. It doesn’t. They could see my screen on the screen share and see there was no proceed dialog. This was red flag #5 as it seemed pretty condescending to suggest I was not using the browser correctly when their goal was to bypass the security mechanism of HSTS, GitLab, nginx, etc, and refused to acknowledge HSTS entirely.

Chrome included the message:

You cannot visit <site> right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.

“If you can’t do it that way then visit it by IP”, the interviewer said. I explained that there was no path in nginx and we would end up at the default backend for nginx. “That should work”, they said. That won’t work. That can’t work. There is no Ingress that matches the IP. There is no nginx host that matches only the IP. Red Flag #6: You will end up at the default backend of the nginx ingress controller and that’s exactly what happened.

“Open it by name on port 80” the interviewer then stated. At this point, I sort of begged that we just wait for the certificates to finish — it wouldn’t take long. Hesitantly, I explained that we aren’t going to be able to visit it on port 80 because HSTS was enabled and I had already visited the site (at the beginning of the tech demo) via HTTPS. “That’s weird. There’s something wrong with your installation. That should work.”

The interviewer was wrong. Again.

Red Flag #7 appears. What the interviewer suggests is a problem with my installation is a feature of the GitLab installation. Visiting by any combination of plain IP, or port 80, or IP:80, or hostname:80… That won’t work. That won’t ever work. That can’t work. Just a few minutes of patience from a Gitlab interviewer to let GitLab get GitLab’s certificates as designed by GitLab Engineers as part of the GitLab Cloud Native Helm Chart would allow us to visit it normally.

During all of this dismissal of my “broken” installation, another interviewer chimed in with “Hey, it loads now”.

Yes. Yes, it does. :)

Strangely, digging into the success of my installation went no further. The interviewers did not ask for accounts to log in with or ask me to visit any status page. For all they knew, ssh cloning was broken or pages beyond the login screen didn’t even work.

All of this, of course, does work in my installation. But why not verify?

I took the opportunity to ask the team if what I had done was not successful or seemed strange. “Most people use Ansible”.