🎉 CNDO #23: GitHub Action permissions

🗓️ What's new this week

🔴 Live show: Join the Future, contribute to open source (Ep 225)

This 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.

Thursday, 7/13 at 13:00 US ET (UTC-4)

👨‍💻 What I'm working on

Helping someone in the real world creates so much more satisfaction than seeing likes on a video you made!  That's probably obvious, but I needed to remind myself of it.

This week and next, I'm running my second live cohort course on tools I love (GitHub Actions and Argo CD), and there's something special when you're able to collaborate with people on solving their problems in real-time.

We have a great group of students who, right out of the gate, are interacting nicely and helping each other. I love it. This is one of the main reasons we are doing these live-training cohorts. Good times.

🧐 GitHub Actions permissions

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

🐦 Tweet of the week

Docker Scout now has a GitHub Action. I'll be talking about this more in the coming weeks

🐳 Swarm Fans meetup was a success!

We've got a growing little Docker Swarm community in the Cloud Native DevOps Discord server. Martin Braun (ancieque) had the idea of hosting these, and Discord's "Stage" channel was a great way to do it.  We had dozens of people come and go during the 90-minute hangout! Thanks to Bjorn Neergaard (Moby and SwarmKit maintainer), Jay Rogers, and others for adding to the conversation!

We're planning the next one in a few months, you'll see it in our Discord server events (and in this Newsletter).

👀 In case you missed it

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

🔴 Live Q&A: Learning Docker and Kubernetes (Ep 224), July 6, 2023

Last week's livestream was our monthly Q&A focused on my Udemy and Maven course content and all things Kubernetes, Docker, GitOps, GitHub Actions, and DevOps-related.😉

Argo CD ApplicationSet is the way to go

🚀 Have you used Argo CD? Argo CD has been revolutionizing Kubernetes deployments the GitOps way. But let's talk about a newer feature that stands out - the ApplicationSet controller!

The ApplicationSet controller is an evolution of the "App of Apps" deployment pattern, enhancing its flexibility to cater to a broad spectrum of use cases. It runs as its own controller, supplementing the functionality of the Argo CD Application CRD and comes installed alongside Argo CD from version 2.3 onward (2022+).

It’s my favorite way to set up auto-deployments for Helm or Kustomize apps, regardless of whether it’s a single chart/app or a monorepo full of many charts/apps and environments.

ApplicationSet is excellent for self-service models and is how I prefer to give Dev team permissions to create their own charts/manifests in their own repos and deploy to K8s clusters without giving them K8s admin powers or control of Argo CD itself.

How can ApplicationSet do this?

💡 Purpose: The ApplicationSet controller serves as an "Application factory". It inputs an ApplicationSet and generates one or more Argo CD Applications. It manages the creation, update, and deletion of Argo CD Applications, ensuring consistency with the declared ApplicationSet resources.

5 reasons why the ApplicationSet controller is a game-changer:

1️⃣ Multi-cluster deployments: With a single manifest, you can target multiple Kubernetes clusters, ideal for managing deployments across different environments.

2️⃣ Multi-repo deployments: Deploy multiple Applications from a single or multiple git repos using a single manifest. This is a significant leap in managing complex application landscapes.

3️⃣ Monorepo support: The ApplicationSet controller improves support for monolithic repository patterns, where many applications/environments are defined in a single repository. This is a big win for teams working on large-scale projects.

4️⃣ Multi-tenant support: It enhances the ability of teams within a cluster to deploy applications using Argo CD, without the need for privilege escalation. This fosters secure and efficient team collaborations.

5️⃣ Generators: The ApplicationSet controller uses "generators" that instruct how to generate Applications. There are different generators to tackle various scenarios and use cases, including the List, Cluster, and Git generators.

Compared to traditional ways of configuring Argo CD, the ApplicationSet feature further automates Application management, reducing PRs and increasing simplicity.