Add 'password' input type for manual workflows

[TaffarelJr]

The input types for manual workflows are great so far:

• string
• choice
• boolean
• environment

But I could really use a password input type.

I need to deploy infrastructure-as-code from my GitHub Action, and I need to be able to prompt for Admin credentials from whoever is running the workflow. I bet I could make it work with a plain string, but I have a feeling my password shouldn't be floating across the internet unprotected. At the very least, a masking effect would be nice to prevent the password from being seen on the screen.

[ethomson]

Appreciate the feedback @TaffarelJr - this is good feedback. There are some details that we'll definitely want to think through because - as you note - these are your secrets. 😁 But your use case makes sense.

Thanks again for the feedback.

[JacobRiske]

@ethomson is there any update on this request?

[Aholicknight]

Has there been any updates for this? I am interested in this as well.

[ravipalla-solasai]

Hi @ethomson

Any updates on Adding password or secret types.

[dev-stupid-codes]

I could be wrong, but I think it's more secure keeping some secrets on my offline password manager. That's why I would rather type passwords each time I need to manually trigger a workflow.

[isacmms]

Bump

[karchun0]

Bump

[milena537blr]

Bump

[luisd-telus]

Bump

[cybernotic]

This is just what I need, a password input type.

[keren-benzion]

This is exactly what I am looking for

[pabloolvcastro]

I would love that

[b4st1en]

Over a year... and nothing new?

I do confirm that it is simply not possible to use Azure (non) secrets (at all) in certain cases. (e.g. echo from some base 64...)
And it's a bit annoying to have to stop sharing your screen in the middle of a meeting just to launch a workflow.

So please add another string type such as masked, password, secret, whatever you like, as long as it has a masking effect when you enter it.

[simonramosb]

Bump

[raja-anbazhagan]

While the comments might help, you might also want to upvote the author's post so it gets more attention.

[gaojx]

Bump

[jeffbraga]

I really want this password type feature too. But while it is not developed, I managed to solve the masked string problem this way.

e.g.

## To avoid expression render ${{ }} and retrieve the value
export SPOTINST_TOKEN=$(jq -r '.inputs.SPOTINST_TOKEN' ${GITHUB_EVENT_PATH})

## Add mask to hide if necessary
echo "::add-mask::${SPOTINST_TOKEN}"

Just read the input directly from the event file that is placed on each run. This way, we don't need to render the ${{ }} expressions where the values ​​are presented and if necessary, add a mask.

Hope this helps.

[bliind]

Using the GITHUB_EVENT_PATH file is amazing and solved my need for handling an input securely. Unfortunately the add-mask line will always output the unmasked content into the logs somewhere, but accessing GITHUB_EVENT_PATH directly in a script worked flawlessly for making sure this input's content never hits the log.

[loewe]

Hi guys,

I wrote a small ViolentMonkey script. It is activated via Shift after the page is loaded :).

// ==UserScript==
// @name        Password protected input fields for github actions
// @namespace   Violentmonkey Scripts
// @match       https://[enter URL here]/SA3/workflows/actions/workflows/*
// @grant       none
// @version     1.0
// @author      -
// @description 28.8.2024, 10:26:06
// ==/UserScript==

'use strict';

window.doTheThing = () => {
    [...document.querySelectorAll('.form-group')]
        .forEach(e => {

            let inputName = e.querySelector('.form-group-header').getElementsByTagName('label')[0].innerHTML;

            if (inputName.includes("password")) {
                e.querySelector('.form-group-body').getElementsByTagName('input')[0].type = 'password';
            }
        }
    );
}

document.querySelector('body').addEventListener("keydown", (event) => {
    if (event.key === "Shift") {
        window.doTheThing();
    }
});

[kosinal]

Bump

[hstravis]

Bump

[DPmax]

almost 3 years, still no update?

[AidanWelch]

This would be very valuable for my initialization pipeline

[isacmms]

At least 2 legit use cases and 3 years since the initial request.
It would be nice to at least have a response on this thread about how is this request being considered and any planning or any information at all to help us track any eventual progress

[hstravis]

We use GitHub workflows for cloud deployments. A password is required to run those workflows. We use the scripts below to avoid having the password printed in logs. Sure would appreciate a "password" input type. Or RBAC for workflows.

DEPLOY_PASSWORD=$(cat $GITHUB_EVENT_PATH | jq -r '.inputs.DEPLOY_PASSWORD')
echo "::add-mask::${DEPLOY_PASSWORD}"

AWK incantations when jq is not available:

DEPLOY_PASSWORD=$(cat $GITHUB_EVENT_PATH | sed 's/[{}]/ /g' | awk -v k="DEPLOY_PASSWORD" '{for(i=1; i<=NF; i++) {if ($i ~ k) {print $(i+1)}}}' | sed -e 's/[",]*//g')
echo "::add-mask::${DEPLOY_PASSWORD}"

[adambirds]

My legit use case on this is as a second line of security. I want to be able to trigger databae restores from actions. But I want to store like a restore password as a secret, and then I can check the input against the secret before triggering a restore. Unless I can somehow limit the trigger dispatch to my user only but still allow other users with the right github pers to execute other workflows.

[Hetzeilen]

As my resource is in Azure I also deployed automation account and have the administrative actions on database from a runbook. This is even more secure as I decorate the automation account with system assigned identity. This identity (through objectId) is assigned the needed roles. The database is configured with AAD auth ('CREATE EXTERNAL', you know) on same service principal and local auth (username/password) are disabled.
I have Ci/Cd on the automation account itself to upload the runbooks and have the runbook sources synched with repository.
Today, in Azure, Logic App (Standard) supports inline code as well so this is an alternative to automation account.
KR,

Edit: as a second thought, yes, with triggers or webhooks you need secrets or tokens. But these are kept in Vault and are retrieved through deployment templates itself.

[lcharest-godaddy]

Ping

[rnayabed]

bumpy

[IlyaKK]

bump

[simonramosb]

Bump!

[MartinLesterSynamedia]

There are work-arounds/hacks but this is such an obvious use case.
I need my (our team's) personal user/pass to access the password store programmatically so we can get all the details for all the systems we then configure (automated Ansible)

• I can't use secrets (or everyone is using my creds)
• We are not allowed automated accounts to access the password store
• I really don't like my password being typed in plain text and plastered all over the logs!

[Marvin-Brouwer]

I would really like this for initial NPM package publish.

NPM supports OIDC now-adays, but only AFTER you publish the package once.
So now I have a workflow_dispatch action that does the initial publish with a short lived AccessToken, and then I setup OIDC on npmjs.com.

This needs to have a sensitive or secret input field.