Skip to content

Approval service does not report workflow parameters #399

@fheinecke

Description

@fheinecke

When releases are started, the user triggering the release must provide GitHub several parameters:

Image

This workflow can be though of as the below function:

func ReleaseTeleport(repo, gitReference, versionToUse, environmentToUse string) {
    // Access secrets, infra, and do release magic
}

This can be triggered by anybody within the https://github.com/gravitational GitHub organization. Any values can be provided.

The purpose of the [GHA] approval service is to prevent a single compromised Teleport employee/their credentials from being able to compromise Teleport, Teleport Cloud, customer envs, etc. by creating a Teleport release. The intent was to collect sufficient information about workflow runs, and require somebody besides the user that triggered the workflow to review the information. If my account was hypothetically compromised by a malicious actor, this service is a security control to ensure that the actor would be unable to trigger a production release without somebody else allowing it.

To be able to determine whether or not a workflow run is malicious, reviewers must be notified not just that a workflow run (that is, a "function call") is being attempted, but also what parameters are being provided.

Today, when an approval request is submitted, it contains only the following information (example from the 16.5.17 release:

Repository: gravitational/teleport.e
Workflow name: Tag Build of gravitational/[email protected]
URL: https://github.com/gravitational/teleport.e/actions/runs/xxxxxxxxxxx
Environment: prod/build
Workflow run ID: xxxxxxxxxxx
Requester: fheinecke

This is enough to determine what version of the workflow, or ReleaseTeleport function, is being executed, but it does not provide any information whatsoever about what parameters were provided. There is no way to tell these two function calls apart from this information:

// Well-intentioned function call
ReleaseTeleport("gravitational/teleport", "v16.5.17", "v16.5.17", "prod/build")

// Malicious function call
ReleaseTeleport("gravitational/teleport", "my-malicious-branch-or-tag", "18.0.0", "prod/build")

As alluded to above, the function accept enough parameters to allow a malicious function call to execute arbitrary code. This allows for not only the single build (and everything it depends on) to be compromised, but also everything that the workflow has access to (AWS infrastructure, long-lived secrets like GPG keys, Apple signing and notarization credentials, etc.).

This completely undermines the reason that the approval service was built for in the first place, and prevents it from providing any real security value. What currently exists today is the equivalent of a lock on a pair of doors - one of the doors may be locked and "secure", but the one next to it is open and unlocked.

To fix this, the approval service needs to record these parameters and make them available to reviewers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingsecuritySecurity Issues

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions