From current documentation in both the Release and Deploy tooling, you can only create Personal Access Tokens (PAT) through the UI of each tool.
We need this both for developing automation around updating/creating PATs that we will be used by Connections in release tasks. It is also necessary since JSESSION/SESSION_XLD type cookies no longer work as we move OIDC/SSO in our tools. Many of our internal maintenance and change processes utilize the REST API via LDAP authentication, using headless/generic service user accounts, that are external to the Deploy/Release instances.
This would be valuable so users of your tools can handle managing their PATs through automation and try to update various Connections made in the Release tooling as needed when PATs begin to expire.
by: Bryan G. | about a month ago | API & CLI tools
Comments
Thank you for the idea. We would like to understand the use case better.
If a token can create further full-permission tokens, expiry stops being a real control. An unattended process could keep renewing its own access indefinitely, and a leaked token would grant not just its own lifetime but the ability to mint replacements. Most tools that offer this either limit what a token created this way can do, or keep a person in the loop. If we build it, we would likely take a similar approach.
A few follow-up questions:
- Would an endpoint that renews an existing token, rather than creating new ones, cover most of your maintenance work?
- Would sourcing these credentials from Vault or Conjur fit your setup, or do they need to live in Release and Deploy?
- If we limited what such a token can do, what would it need to cover? Knowing which specific operations your automation performs would help us define a safe scope.