I’m part of a team that works on the a plugin called ’ Atlassian Jira Software Cloud’ which, when installed in a Jenkins server allows you to send CICD data to Jira. We’re currently looking into ways we can update the plugin but want to feature flag any changes we make so we can roll them back and have a safe way to revert any changes that happen to go sideways. To make this happen, we need to store a SDK key for LaunchDarkly… somewhere.
I know the credentials provider can be used to store env vars at the ‘server level’ but this needs to be defined only by our plugin → https://github.com/jenkinsci/atlassian-jira-software-cloud-plugin/blob/9962b1484761d82ea8b35005892848dca9dc2dab/src/main/java/com/atlassian/jira/cloud/jenkins/featureflagservice/FeatureFlagService.java. It’s not something that can we defined and added by users of our plugin.
Is there a way to do this?
I don’t think you can make your plugin use a key for querying feature flags but prevent the key from being revealed via Script Console in Jenkins. Especially not if your plugin is distributed at plugins.jenkins.io, which requires a free software license and public source code.
The Client-side, server-side, and edge SDKs documentation warns against disclosing server-side SDK keys; but it lists only a server-side SDK for Java. I think you have these options:
- use a server-side SDK key despite the warning, and hardcode it in the plugin. Be careful not to add any personal or confidential information to the rule set that can be read by using this key. Ask their customer support what other risks there are with disclosing the key — for instance, whether malicious requests made with this key could affect your billing. Revoke the key if it is abused.
- use a different feature-flag service that supports public keys in Java. I don’t know whether one exists. Server Keys, Mobile / App Keys and Browser / Public Keys claims to have Java SDKs for “Server Keys” and “Mobile / App Keys”, but not “Browser / Public Keys”.
- use some other kind of cloud service, rather than one dedicated to feature flags. A public S3 bucket perhaps. But then you might have to implement local storage as a fallback for offline usage yourself.
- make Jira Cloud publish the feature flags, instead of using a third-party service. I presume the plugin already authenticates to that. The feature-flag API could perhaps be part of your ”Jenkins for Jira (Official) by Atlassian” app.
- withdraw the plugin from plugins.jenkins.io and make it proprietary with obfuscated code and an an EULA that forbids looking at API keys.