🎉 CNDO #24: Improve your security in CI and containers

🗓️ What's released this week

🔴 Livestream - Cloud Native DevOps: Live Q&A (Ep 226)

Today, Nirmal Mehta and I will do a 100% ask-me-anything with you! We'll be focused on your cloud native DevOps questions: containerization, orchestration, automation, infrastructure, and more. Bring your questions.

🎧 Podcast

Ep 136: Cycle.io LowOps container platform

Last week, we released a podcast where Matt and I welcomed Jake Warner back to the show to talk about LowOps. What does LowOps mean? What can Cycle offer us as an alternative to Swarm and Kubernetes?

Jake is the CEO and founder of Cycle.io. And I had him on the show a few years ago when I first heard about Cycle and I wanted to get an update on their platform offering. On this show, we generally talk about Docker and Kubernetes but I'm also interested in any container tooling that can help us deploy and manage container based applications. Cycles' platform is an alternative container orchestrator as a service. In fact, they go beyond what you would provide normally with a container orchestrator and they provide OS updates, networking, the container runtime, and the orchestrator all in a single offering as a way to reduce the complexity that we're typically faced with when we're deploying Kubernetes.

While I'm a fan of Docker swarm due to its simplicity, it still requires you to manage the OS underneath, to configure networking sometimes, and the feature releases have slowed down in recent years.

But I still have a soft spot for those solutions that are removing the grunt work of OS and update management and helping smaller teams get more work done. I think Cycle has the potential to do that for a lot of teams that aren't all in on the Kubernetes way, but still value the container abstraction as the way to deploy software to servers.

🗣️ Conference Talk Released from Civo Navigate

Civo released my talk from Feburary 2023. I'm proud of how quick this came together. For context, I had to build this while having Covid, which was while I was recovering from the Flu. I was unrehearsed, and had too many slides (some weren't even finished) but I plan to continue improving and deliver it again.  I have an empty repo that I hope to fill with the links and recommendations I make in the presentation.

🐦 If you have feedback or questions, I'm discussing it on Twitter.

👨‍💻 What I'm working on

Finishing up the cohort

We're finishing up our 2nd week of my GitHub Actions + Argo CD automation cohort. After a brief time to make improvements to the cohort, my wife and I will take advantage of some fun things in our neighborhood, as well as turning our attention to our continued work on updating our Docker Mastery course on Udemy.

🗣️ DockerCon CFP talks submitted!

I will be at DockerCon 2023 (Los Angeles in October) and hope they'll have me again as a speaker.  I've submitted multiple talks.
Also, my friend and fellow Docker Captain Nirmal Mehta and I have submitted a talk on "a containers journey from dev to prod". I haven't done a talk with Nirmal before and I'm really excited about it. He's a good storyteller and I think stories make the best conference talks. Hopefully, we'll be accepted. Regardless, I'm super thrilled to go to DockerCon again IRL!!

👀 In case you missed it

(headlines from last week's newsletter that you can skip if you already read it)

🔴 Live show: Join the future, contribute to open source (Ep 225), DATE +YEAR

Last week, Nirmal and I will welcome Brian Douglas on the show. Brian, of GitHub Developer Advocacy fame (you've probably watched or read something he's created), is the founder and CEO of Open Sauced where he works on increasing the knowledge and insights of open-source communities. We're going to talk about open source, its value, how to be involved and create opportunity from it.

🧐 GitHub Actions permissions

In last week's newsletter, I shared a post:

GitHub Actions is seeing rapid adoption, and it’s my go-to automation solution for Kubernetes and Docker CI/CD workflows. My clients love it, and many are migrating to it as their primary automation tool.

⚠️ One implementation detail that’s not getting enough attention is to always add permissions in the YAML. They aren’t always required, but there are multiple reasons you should always add them.

👏 We want a “least privilege” design. This means our workflows should start out with as little read-access as possible and no write-access unless required by the steps in that workflow and job.

💡 To start, you can set the default Actions permissions to read-only in the org and/or repo settings. This ensures no write-access and only limited read-access to files and packages. GitHub was smart to change the default setting recently to read-only.

🤓 But we can’t depend on those settings being set correctly everywhere, so I recommend you always add a permissions list to the YAML. You can add at both the Workflow and Job level, so keep it simple at first, and just add the list at the top Workflow level.

Imagine you’re starting with this Workflow policy, which is the permissions you get when creating a new repo:

permissions:
  contents: read
  packages: read

👉 Now, you can either think about what your workflow is doing and guess the additional permissions it’ll need (adding from the list below), or you can just try running it with that minimal permission set and see what steps fail.  The results may surprise you, especially if you always run them with the default “read/write everything” permissions.

🙏 This effort will ensure you have a “least privilege” model for your workflows, and when you share or reuse those workflows elsewhere, it’ll work regardless of what their org and repo default security is set to.

🎉 It also has the benefit of documenting your permissions in the workflow itself, so you can point other people to the YAML lines to see exactly what resources the GitHub Action runners have access to for that Workflow automation. The topic of “what does our CI/CD tool have access to?” will likely come up during a security audit, and in my experience, proving the permissions in a few short YAML lines makes it a much easier conversation.

🔒 This is the full list of permission options in a GitHub repository:

actions: read|write|none
checks: read|write|none
contents: read|write|none
deployments: read|write|none
id-token: read|write|none
issues: read|write|none
discussions: read|write|none
packages: read|write|none
pages: read|write|none
pull-requests: read|write|none
repository-projects: read|write|none
security-events: read|write|none
statuses: read|write|none

🐳 Swarm Fans meetup was a success!

We've got a growing little Docker Swarm community in the Cloud Native DevOps Discord server. We had dozens of people come and go during the 90-minute hangout! We're planning the next one in a few months, you'll see it in our Discord server events (and in this Newsletter).