profile
viewpoint

Ask questionsAbility to detect user who initiated build

Context

I am part of a team that maintains a suite of software used for deployment and CI/CD internally within my company. We maintain a set of hosted services that run the actual deployments, as well as a client application used to interact with those services. This client application can be run locally or run within the context of a Concourse pipeline for automation of these deployments. We are currently in the middle of a push to increase the visibility and auditability of deployments made using our tooling.

What challenge are you facing?

With the current stateless design of Concourse and the intentional limiting of information, I lack two very distinct capabilities that are limiting my team's ability to effectively use Concourse:

  1. We do not have the ability to link a particular build to the user who triggered it (or if it was automatically triggered), preventing us from auditing builds or back-tracing issues that arise from an erroneous build.
  2. We lack the ability to detect if we are running within Concourse, meaning we cannot enable selective behavior (such as only permitting certain actions within the context of a Concourse pipeline and not permitting those actions for a local run of the binary, or vice versa) without maintaining two separate editions of the binary in question (one for Concourse, one for local runs), a significant increase in project maintenance.

Of the two, the first one is the more critical for our use case. Our Concourse server is integrated with our corporate SSO system, but the user information is not exposed to the pipelines, so our build process cannot detect who initiated a particular build (or which pipeline initiated it, or if it was automatically triggered). This seriously limits our ability to audit deployments and builds, and do any sort of forensics if we encounter issues with a build down the line (especially since the pipeline-specific and build-specific information appears to be completely deleted if the pipeline itself is deleted). We can collect this information if the deployment is triggered using a local run of the client binary, but not if it is triggered via Concourse.

What would make this better?

Exposing the user information to the build process, perhaps through environment variables or some sort of local metadata service we could curl to. Implementing a solution to 1) will most likely effectively solve 2) at the same time.

Are you interested in implementing this yourself?

Unlikely I'd have the bandwidth to do so.

concourse/concourse

Answer questions chrised

+1 from myself and my team also, we'd really like this for SOC 2 Compliance; otherwise we're probably going to have to resort to deploying something like RunDeck alongside our Concourse deployment, which would suck.

useful!

Related questions

Input scripts lose executable bit (Windows 10 Docker host, GitBash shell) hot 1
USABILITY: Make a missing task image/image_resource have a better error message hot 1
No resource type out-of-the-box with windows worker hot 1
DNS fails to resolve - missing iptables rule hot 1
Cannot login to Concourse Web using Firefox hot 1
Cannot login to Concourse Web using Firefox hot 1
File perms are not preserved in `fly execute` hot 1
Baggage claim not removing containers/volumes hot 1
USABILITY: Make a missing task image/image_resource have a better error message hot 1
500 error on badly cleaned up containers/workers hot 1
500 error on badly cleaned up containers/workers hot 1
OIDC with Okta doesn't get username or groups hot 1
Vault multi-line values are not supported - no support for ssh-keys through vault? hot 1
Flake: `iptables: create-instance-chains: iptables: Memory allocation problem.` hot 1
5.0 upgrade: ErrAuthNotConfiguredFromFlags hot 1
source:https://uonfu.com/
Github User Rank List