Sec on Ely Clover

Google Artifact Registry is replacing Container Registry

kevin@elyclover.com (Kevin Holmes) — Tue, 08 Aug 2023 10:00:00 +0000

You may have seen the warnings in your Google Console recently: the Google Container Registry (GCR) product will be deprecated in May of 2023 in favor of Google Artifact Registry (GAR.)

Whenever I see these kinds of warnings as an engineer on a DevOps, Infrastructure, or Platform team (how many ways can we be classified?!), my heart tends to drop into my stomach a bit because it means a vendor has tossed another bundle of work onto what’s likely an already overloaded plate. Since we’re all trying to think more positively these days (I hope), let’s discuss why this can be a Good Thing (tm) for all of us, especially when considering DevSecOps and Cybersecurity principles within a Google Cloud environment.

Eliminating Service Account keys in self-hosted Actions CI/CD environments

kevin@elyclover.com (Kevin Holmes) — Wed, 02 Aug 2023 10:00:00 +0000

If you’ve been paying attention to the Federal guidance from the Whitehouse over the last couple of years, there’s a slice dedicated to securing the software supply chain. This shift isn’t a big shocker to anyone keen on cybersecurity or national security topics. Supply chains for physical goods are the lifeblood of a nation’s economy, the same goes for non-tangible goods like software and the platforms it runs on. If you’ve been in the field for a while, I’m sure you’ve heard about the Solarwinds hack, and plenty of others in the past could have been better publicized, considering how nefarious they were.

When should I self-host GitHub Actions runners? (part 1)

kevin@elyclover.com (Kevin Holmes) — Mon, 31 Jul 2023 10:00:00 +0000

As 2023 flies by and the Cybersecurity incidents making headlines continue to roll in, I would like to discuss self-hosting your own GitHub Actions infrastructure.

First, I always encourage teams to use hosted solutions when possible. The keyword here, and in most good systems engineering, is “where possible” - which can be the hardest part for teams to isolate and identify given their backstory, knowledge gaps, and regulatory environment(s). For instance, I’ve seen powerful DevOps, Infrastructure, or Platform engineering teams decide to self-host Actions Runner environments because they have the resources and buy-in from management. However, there’s no strong reason beyond the team wanting to do it and thinking they have the free cycles. This kind of thinking is a classic trap for engineering teams because the objective is a sexy one, and I can’t deny that. GitHub Actions are getting more popular by the day, and it’s certainly a hot topic among teams already using GitHub for source control or considering the move from competing well-established ecosystems like GitLab, Gerrit, Jenkins, and similar alternatives.

Governance of 3rd party GitHub Actions in GHES instances

kevin@elyclover.com (Kevin Holmes) — Fri, 28 Jul 2023 10:00:00 +0000

After spending a few years using GitHub Actions in Open Source, Commercial, and FedRamp environments, I wanted to share some of my takeaways for a few options on how to provide governance over what Actions you allow to be used within your self-hosted GHES and Actions runner instances. This article will focus on government or commercial users self-hosting source code (GHES) and the Actions runners in their secured environments.

There are two paths if you boil this down: