Default Admin API Token

[Shahbaz Subedar]

Hello Team,

I have been trying to implement the functionality of having default Admin API token at the time of deployment of Jenkins. I have been following the below link.

https://github.com/jenkinsci/jenkins/pull/4027/commits 

As per the instruction, I have setup the system properties with fixed token, but still not able to use the same token to access the API.

I have been using Helm chart to deploy the jenkins with version as = 2.261.

Here are some details of my values.yaml file.

global:

  hosts:

    domain: ${domain}

master:

  resources:

    requests:

      cpu: 512m

      memory: 512Mi

  javaOpts: >-

    -Dhudson.model.DirectoryBrowserSupport.CSP="default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' 'unsafe-inline' data:;"

    -Dcasc.jenkins.config="/var/jenkins_home/casc_configs"

    -Djenkins.install.runSetupWizard="false"

    -Djenkins.install.SetupWizard.ADMIN_INITIAL_API_TOKEN=11b9b3fafe25923768621ca1b64d44bfd1

    -Djenkins.security.ApiTokenProperty.adminCanGenerateNewTokens="true"

    -Djenkins.security.ApiTokenProperty.showTokenToAdmins="true"

  tag: 2.261

  useSecurity: true

  adminUser: "shahbaz"

  adminInitialApiToken: "true"

  JCasC:

    enabled: true

    defaultConfig: false

    configScripts:

      jenkins-settings: |

        jenkins:

          authorizationStrategy:

            loggedInUsersCanDoAnything:

              allowAnonymousRead: false

          securityRealm:

%{if persistence == true }

            keycloak

%{ else }

            local:

              allowsSignup: false

              users:

              - id: "admin" 

[Shahbaz Subedar]

Can you please reply to this ? If someone has tried to implement the same

[Daniel Beck]

> On 1. Dec 2020, at 11:40, Shahbaz Subedar <shahbaz...@gmail.com> wrote:
>
> -Djenkins.install.runSetupWizard="false"
> -Djenkins.install.SetupWizard.ADMIN_INITIAL_API_TOKEN=11b9b3fafe25923768621ca1b64d44bfd1
>

You're disabling the setup wizard, and then set an option that is

> only used before/during the Setup Wizard

[Tim Black]

Daniel Beck, as I commented on the related closed jenkins issue, I can't understand the usefulness of this feature for automated installs, which inherently will be setting `jenkins.install.runSetupWizard = false`. Can you help me understand the use case for this PR?

I'm trying to achieve essentially the same thing (want to pre-seed an api token to enable api access during initial jenkins provisioning), and months ago came to learn (via gitter) of the new Djenkins.install.SetupWizard.adminInitialApiToken option. I'm on 2.289.1 and Djenkins.install.SetupWizard.adminInitialApiToken=<my-pre-determined-34-char-token> simply has never worked for me.  The docs for this option indicate that it:

> determines the behavior during the SetupWizard install phase concerning the API Token creation for the initial admin account.

So, it would seem for automated installs like ours which must disable the setup wizard, this option is innefectual, by design. No? 

On Gitter, Tim Jacomb pointed me to the PR that introduced this feature by Wadeck Follonier, whose description seems to indicate this is by design:

> No impact once an instance is configured.

Any advice? I tried it with and without running the setupwizard, and I've never been able to use the token to authenticate as my admin user in a new Jenkins instance.

So far, the big items I want to use the API for during provisioning are mostly putting jenkins into quietDown mode and safeRestarting - the former only useful during subsequent ansible provisioning, and the latter, which can also be done by simply restarting jenkins service, is required to absorb the build history which we're copying over from the production jenkins controller during provisioning.

More importantly, having a pre-baked API token would be highly useful for implementing test automation in the provisioning (ansible) playbooks. Using CasC to automate configuration is great, but insufficient in the same way that adding a new feature to any software project is insufficient until there are automated tests that can validate the new behavior.

Should I just give up on the Djenkins.install.SetupWizard.adminInitialApiToken approach and roll my own automation using the old-school crumb (CSRF token) approach?