Daily Dose of DevOps — GitHub Actions basics for DevOps

GitHub Actions is an automation tool that combines several components to provide secure, event-based workflows. These components include an event system, workflow scheduler, ephemeral compute, and a credential broker. The primary security concern with GitHub Actions is not whether the YAML code is executing, but rather what level of authority untrusted input, such as branch names, commit contents, issue text, or third-party action outputs, can exert.

When a workflow is triggered by content in a pull request, it exists on a trust boundary. This means that various elements like branch names, commit contents, issue text, and third-party action outputs could potentially be controlled by an attacker. To mitigate this risk, it is essential to minimize authority. Permissions should be explicit and scoped to the specific jobs they are needed for.

Build jobs typically require read-only access to the repository, while deployment jobs can be granted stronger permissions only after passing through protected environment controls.

OpenID Connect is recommended over long-lived cloud credentials. With OpenID Connect, a short-lived, claim-bound identity is exchanged at runtime, reducing the risk associated with long-lived credentials. Permissions for jobs should be defined using the `permissions` keyword, specifying which actions the job can perform. For example, a job dedicated to deployment might be granted permissions to read the repository contents and write an ID token.

To ensure the security of third-party actions, it is crucial to pin them to immutable commit SHAs (Secure Hash Algorithms). This helps maintain the integrity of the actions and prevents malicious updates. Review the provenance of these actions and utilize dependency automation to propose controlled updates, ensuring the codebase remains secure.

When utilizing third-party actions, it is important to treat workflow logs and artifacts as potential exfiltration channels. While masking sensitive information can provide some protection, it is not a substitute for preventing secret exposure in the first place. To enhance reproducibility and manage concurrency, use lockfiles and deterministic installation commands.

Keep build and deployment processes separate, promoting the same verified artifact to different environments. Apply concurrency groups to prevent stale deployments from competing with newer commits. Carefully consider cancellation semantics for stateful operations to minimize potential security risks. Ultimately, workflows should be modeled as programs that execute with capabilities and handle untrusted inputs.

Grant the minimum token permissions at the narrowest job scope, prefer short-lived federated identity and immutable dependencies, build once, verify provenance, and then promote the identical artifact through various environments. By following these guidelines, developers can build a secure and efficient DevOps workflow using GitHub Actions.