If you’re seeing this article it’s probably for one of two reasons:
Either way, it’s a positive that you’re here. By the end of this article you’ll hopefully see how using “@here” is usually bad Slack etiquette and how it affects the team as a whole.
Let’s start by covering when you should use “@here”:
There are many places that workloads should be secured: In CI, within the cluster (securityContext & security policies), outside the cluster (firewalls), etc.
This article will specifically cover securing workloads with some Docker best practices and Kubernetes securityContext. These two sides go hand-in-hand to restrict inappropriate activities within the container.
Awake now? good stuff!
Let’s create a simple Dockerfile and build an image:
If we run the above image, what user do you think we’ll be using?
$ docker run --rm -it $(docker build -q .)
uid=0(root) gid=0(root) groups=0(root)
If you guessed root, you guessed right.
I’m guessing if you’re reading this article, you already know the answer to that question but I’ll leave a couple brief points here that you can research further if you’re interested. …
Errors are stressful, especially when they aren’t meaningful and early.
In modern agile landscapes where developers and operations work together, there’s a big issue and that is the lack of clear communications.
How often do you see an error or failure only to think to yourself “but… I didn’t change anything!”, a ticket and a headache later you realize that the cluster has changed not your application and you weren’t notified. There are changes happening all the time, how would a platform engineer even notify a developer of so many changes?
If there is a new security requirement at the cluster level, how is that communicated to the app-teams and then enforced without failures and delays? …
It is essential that you export your data to somewhere other than GCP. Whilst GCP is an awesome cloud provider and the odds that Google goes bankrupt taking your workloads with it is extremely unlikely it is entirely possible that someone or some process (malicious or not), deletes your data in the cloud.
It’s for this situation that we need business continuity, disaster recovery, and all the other good buzz words that effectively mean, “to un-screw that which is effectively screwed”.
So you moved your databases to “the cloud”, good stuff!
Let’s assume we’ve configured Cloud SQL Backups for our instances and our backups a stored within a GCS bucket inside the same project (because they are, that’s where Google stores them). What happens if someone or something accidentally deletes bucket? …
Programming is for everyone, not just “Developers”
I remember being in primary school when I was asked what I wanted to be when I “grow up”. I answered “Computer programmer” without even knowing what that meant.
Programming for a career is usually referred to as being a Developer. I’ve been programming in some fashion since I was a teenager but I’ve never had the job of “Developer”.
At this point in my career I’m a DevOps engineer/consultant. DevOps is more a methodology or a philosophy than a single job but in terms of a job, you could think of it as someone who works in both the systems operations space and assists with development but does it in a repeatable, reliable, deterministic way. It’s a kind of jack of all trades role where you are responsible for setting a good example when it comes to code, infrastructure, and other technological tastiness. …
I’ve written this article specifically for Go developers who are interested in CI within GCP — so if that’s you, you’re in the right place! I will intentionally skip steps along the way but where possible, I’ve included links to other tutorials or documentation on the steps excluded for those who would like to build or refresh their skills.
After you’ve gone through this tutorial, you should have the basic structure of a robust and secure CI pipeline for use with many different Go projects.
The software industry as a whole, has adopted build pipelines as a means to deliver reliable, deterministic, and production ready applications. To achieve these intrinsic goals in this example we will create multiple steps in our build pipeline to assist us, such as editor-config checks, linting, Go tests, and secure code analysis. This ensures that our resulting artefact has passed every one of our high standards. …