Hi Steve,
API uses a user account from the instance, so any Jira user that has permissions to accomplish what you require is fine to use.
In addition, we have the ability to use API tokens in Cloud, which is something that Jira Server doesn't have.
With this, you can generate a token from your login, and use that to authenticate API.
Let me know if you have any questions.
Regards,
Shannon
Good morning Shannon,
We want to protect against the possibility of our admin hitting the lottery and leaving for a permanent vacation and having all API keys he/she generated become deprecated when we offboard him/her.
Does this mean we'd have to make a separate account, give it admin access and then generate the API key? Ideally we'd like to not consume a license to generate keys, just wanted to know if there was a way around this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jonathan,
Great question! Thank you for reaching out.
As you suspected, the token is tied to the user's account. So if you disable that user in Jira in order to free up the license, then the tokens will no longer be able to be used.
In that case, you will indeed want to have your new admin generate new tokens, and you can update your API calls to use the new token. The user who generates the token does need to be tied to a license in order for it to work. There is not a way around this.
I hope that clarifies things for you! Let me know if you have any further concerns.
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
It occurs to me that this solution is a potential security risk,
Let's say I have repositories A and B, repository A is open to my coworker John but not repository B.
I setup repository A's pipeline with variables UPLOAD_ACCOUNT and UPLOAD _PASSWORD pointing to my account and an app password with only read and write permissions (as required per bitbucket-upload-file for example)
John can now access repository B of which he does not have access, by pushing a clever bitbucket-pipelines.yaml to repository A, that takes advantage of UPLOAD_ACCOUNT and UPLOAD _PASSWORD to fetch repository B with my credentials (and upload it to my competitors, on my own pipeline bill!, damn you John, freaking corporate spy!)
This is possible because app passwords are not limited to a subset of repositories I own, with one app password you can access all my repos.
In that case I could create a user that can only have access to the repo I want to automate, but when I have 5 repos that need to be exclusive from each-other I then need 5 accounts, which -not regarding the cost on my plan- are a pain to manage as they are "real people" with real Atlassian accounts.
In short, I would not advise people to include app passwords in pipelines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This! So very much this!
Even if "John" is not uploading data to another company, the actions taken are on Renaud's credentials, yet it was "John" that performed the task.
This action alone violates SOC2 Type 2 compliance in that we have to be able to report who did what and when it was done. In this case "John" did an action, but the paper trail points to Renaud.
Not good at all.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So, in true Atlassian style, yes you can have a service account but you'll need to pay for it like a normal user. SMH
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry, but I don't see how the current setup solves the issue with establishing stable integration in case if user leaves organization. Why we need to use actual user account to configure an integration for the company? Why service account can't be created just for the integration purposes ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Igor,
Thank you for the feedback.
Creating an API token requires a specific user to do it because the token will then be based on their permissions in Jira. This is for security reasons. You can still create an account on Jira to JUST connect to the API and create a token with that.
Let me know if you have any questions about that!
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I was wondering if there is a way to differentiate accounts created towards integrations and not to count them towards the paid number of user seats.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Igor,
Thank you for following up.
You need to have a license on the account in order for it to interact with Confluence's data in any way, including via API. There is unfortunately no way around this.
Thank you for your understanding!
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have a use case for this as well, a service account would be helpful and to not take up a user seat. Actually, I would prefer to create to service keys one for my dev environment and one for production.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The problem with this is that it creates a requirement to share credentials for that integration account in order to generate new API keys. Shared credentials to access functions that aren't otherwise accessible to Site Administrators when they need it seems to violate some rather basic security practices. I don't particularly have an issue with using a user seat to set discrete permission sets for different integration accounts if necessary, but having the ability to regenerate keys or generate new keys as a site administrator for a service account seems like a generally useful capability.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can I create one dedicated Jira user account to be used for all integrations that requiere the same privilege access? ex. Say I need to integrate Jira with Jenkins as well as with GitHub... can I use the same Jira service account? My next question is... can a single jira service account be assigned more then one token? or one token per account and per integration regardless of privileges needed?
Lastly,
What Atlassian recommends as best practices to set up app integration with its products, and how to manage the service accounts to create, maintain, and eventually decomission this accounts and integrations?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Good question. I'd also like to know the answers for this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What admin role should the service account possess? i.e (product, site, organization)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello @Dan.anas,
Thank you for following-up here. This entirely depends on what functionality you need that account to have.
For example:
I hope that's clear! Let me know if you have any further questions.
Regards,
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Shannon S ,
To make sure I understand, I can do the following...
1. Create a Jira Cloud user API_Service123@mycompany.com with Jira-User, Jira-Software-User permissions.
2. Generate an API token
3. Give my API Developer the credentials- API_Service123@mycompany.com and API token (password)
4. Done?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I am looking for answers to above questions @[deleted] can you please address, Thanks in advance
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Varun kumar thupakula @JRodney Estrada
Apologies, I didn't see your reply to this question since it's a few years old.
That's correct - you can use the procedure from our developer site:
If you have any trouble, please raise a new question, so it doesn't get overlooked.
Thank you!
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You're welcome, happy to help!
Shannon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.