Support Hardened Self Hosted GitHub Actions Runners

[bloudraak]

The integration between 1Password and GitHub Actions really benefits production deployments, however, but with that, comes environments that are often locked down due to the data that deployment systems can potentially access. There are several cases where malicious actors target CI/CD systems to gain access to production, either by disclosing secrets used during deployments, or by compromising binaries that in turn could result in disclosure later on.

In these environments:

1. A GitHub Actions Runner may be built using Packer which then installs all prerequisites (including 1Password CLI), and packages may be pinned
2. Any deployment tasks would be executed with a restricted account (no sudo access, limited write access)
3. The runners, when deployed will be in an environment where access is deny by default, with explicit ports and hosts being opened (for example, the runner may talk to GitHub, 1Password Connect, vCenter, and specific networks)

Approaches to supporting 1Password

1. Attempt to discover the 1Password CLI that's already installed, which seems to be /usr/bin when installed with apt. (Use your own documentation as the locations where the CLI may be installed)
2. If (1) fails, allow the user to specify a location from which 1Password CLI can be downloaded; typically an internal system such as Artifactory, SMB share, HTTP endpoint.
3. If (1) and (2) fails, attempt to download 1Password from the default HTTP endpoint

Things to consider. Packages/Binaries are often scanned, index and cataloged, and then approved (often based on agreements with vendors), and that's one of the reasons downloading or installing files during the build isn't permitted. From a release engineering perspective, the ability to ensure everyone is using the exact same toolchain helps minimizing issues and churn.

Another thing to consider is that when you're following hardening guidelines published by the CIS Benchmarks, you'd typically ensure noexec option is set on /tmp and /var/tmp partitions, which makes the current action fail. There's a bunch more to consider, but it's probably best to refer to the CIS and STIGs.