hmac
is a tool to update the HMAC token, GitHub webhooks and HMAC secret
for the orgs/repos as per the managed_webhooks
configuration changes in the Prow config file.
To run this tool, you'll need:
-
A github account that has admin permission to the orgs/repos.
-
A personal access token for the github account. Note the token must be granted
admin:repo_hook
andadmin:org_hook
scopes. -
Permissions to read&write the hmac secret in the Prow cluster.
There are two ways to run this tool:
- Run it on local:
go run ./prow/cmd/hmac \
--config-path=/path/to/prow/config \
--github-token-path=/path/to/oauth/secret \
--kubeconfig=/path/to/kubeconfig \
--kubeconfig-context=[context of the cluster to connect] \
--hmac-token-secret-name=[hmac secret name in Prow cluster] \
--hmac-token-key=[key of the hmac tokens in the secret] \
--hook-url http://an.ip.addr.ess/hook \
--dryrun=true # Remove it to actually update hmac tokens and webhooks
- Run it as a Prow job:
The recommended way to run this tool would be running it as a postsubmit job. One example Prow job configured for k8s Prow can be found here.
Given a new managed_webhooks
configuration in the Prow core config file,
the tool can reconcile the current state of HMAC tokens, secrets and
webhooks to meet the new configuration.
Below is a typical example for the managed_webhooks configuration:
managed_webhooks:
# Whether this tool should respect the legacy global token.
# This has to be true if any of the managed repo/org is using the legacy global token that is manually created.
respect_legacy_global_token: true
# Controls whether org/repo invitation for prow bot should be automatically
# accepted or not. Only admin level invitations related to orgs and repos
# in the managed_webhooks config will be accepted and all other invitations
# will be left pending.
auto_accept_invitation: true
# Config for orgs and repos that have been onboarded to this Prow instance.
org_repo_config:
qux:
token_created_after: 2017-10-02T15:00:00Z
foo/bar:
token_created_after: 2018-10-02T15:00:00Z
foo/baz:
token_created_after: 2019-10-02T15:00:00Z
Suppose the current org_repo_config
in the managed_webhooks
configuration is
qux:
token_created_after: 2017-10-02T15:00:00Z
foo/bar:
token_created_after: 2018-10-02T15:00:00Z
foo/baz:
token_created_after: 2019-10-02T15:00:00Z
There can be 3 scenarios to modify the configuration, as explained below:
User updates the token_created_after
for foo/baz
to a later time, as shown below:
qux:
token_created_after: 2017-10-02T15:00:00Z
foo/bar:
token_created_after: 2018-10-02T15:00:00Z
foo/baz:
token_created_after: 2020-03-02T15:00:00Z
The hmac
tool will generate a new HMAC token for the foo/baz
repo,
add the new token to the secret, and update the webhook for the repo.
And after the update finishes, it will delete the old token.
User adds a new repo foo/bax
in the managed_webhooks
configuration, as shown below:
qux:
token_created_after: 2017-10-02T15:00:00Z
foo/bar:
token_created_after: 2018-10-02T15:00:00Z
foo/baz:
token_created_after: 2019-10-02T15:00:00Z
foo/bax:
token_created_after: 2020-03-02T15:00:00Z
The hmac
tool will generate an HMAC token for the foo/bax
repo,
add the token to the secret, and add the webhook for the repo.
User deletes the repo foo/baz
from the managed_webhooks
configuration, as shown below:
qux:
token_created_after: 2017-10-02T15:00:00Z
foo/bar:
token_created_after: 2018-10-02T15:00:00Z
The hmac
tool will delete the HMAC token for the foo/baz
repo from
the secret, and delete the corresponding webhook for this repo.
Note the 3 types of config changes can happen together, and
hmac
tool is able to handle all the changes in one single run.