Jira Connector EMail and API-Token

Elastic Stack Kibana
1

Hi,
to create a Jira connector in Alerts and Actions, Email and API token are required fields. I can't find any information, how to configure this in Jira. Do I have to define an application in Jira ? But no email is necessary for an application in Jira.

Can anybody help or provide a link to the documentation for this Jira connector ? Thanks in advance .

Best reagrds,
Norbert

2

Let me know if this helps: https://www.elastic.co/guide/en/elasticsearch/reference/current/actions-jira.html

3

Unfortunately not. The configuration for Watcher is fine and we use it, but if you look at the mandatory fields for the Jira Connector in the new Alerts and Actions framework, these fields Email and API token are what I have a problem with.

image
image960×543 34.4 KB

4

Hi, @norgro2601!

If you have a cloud instance your account is email-based and you can create API tokens from your account's management page. You can read more here: https://confluence.atlassian.com/cloud/api-tokens-938839638.html

If your instance is self-hosted API token authentication is not supported. Nevertheless, you can put your username in the email field and your password in the API token field and the connector should work without issues.

The labeling of the two fields was improved in https://github.com/elastic/kibana/pull/69892

Let me know if that worked for you.

Best,
Christos

5

Hi, @christos.nasikas,

unfortunately this doesn't work. I've entered the credendials and I can save it, but when I reopen the Connector settings, the entries are gone. I've upgraded the instance to 7.8.1 tonight to have the latest changes available. Could it be a problem, that the usernames we use are the email addresses and that misleads in the code ?

Best regards,
Norbert

6

Hi, @norgro2601,

This is the expected behaviour. The credentials in the connector's update form (the flyout that is being shown when you press the Update connector button) are not being there in purpose. All other fields should be presented. Nevertheless, the credentials are saved and the connector can be used. The format of the username shouldn't matter. Did you try to push a case to Jira? Did you get an error?

7

Hi @christos.nasikas,

Thanks for the explanation. No, I didn't test, because I thought, this will not work. I will do a test now and let you know the result.

8

Hey @norgro2601!

How was the test? Do you need any help?

Best,
Christos

9

Hi @christos.nasikas,

I still get an error. I've created a case in SIEM, but when I use the "Push as ... incident" button, I get this error:

image
image705×314 16.1 KB

Best regards,
Norbert

10

Hi @christos.nasikas,

I forgot to mention, our stack is running in Elastic Cloud. Maybe I need to add something in the keystore settings like I've done to get this working with Watcher ?

Best regards,
Norbert

11

Hi @norgro2601!

That is an interested one :slightly_smiling_face:. Your Jira connector is set up correctly.

For some reason, the request being made to your Jira instance is malformed and you get a Bad Request (400 status code).

Could you please try this and tell me if you get an error?

curl -u username:password --location --request POST 'https://<your_instance_url>/rest/api/2/issue' \
--header 'Content-Type: application/json' \
--data-raw '{
	"fields": {
		"summary": "issue from case",
		"description": "description from case",
		"project": {
			"key": "<your_project_key>"
		},
		"issuetype": {
			"name": "Task"
		}
	}
}'

Best,
Christos

12

Hi @christos.nasikas,

the curl statement works with two small changes.
The first one is probably related to the os I'm using. I had to change --data-raw to just --data, because --data-raw option is not available.
The second one is the issuetype, I couldn't take "Task", because this type is not allowed in the project I wnat to send to.
The test-ticket was created then.

Best regards,
Norbert

13

Hi @christos.nasikas,

I've looked at the api documentation.
https://www.elastic.co/guide/en/siem/guide/current/register-connector.html

In the Jira action, I miss the issuetype, do you always take "Task" as a default. As mentioned before, "Task" is not a valid option in the project I want to send to, maybe this is the problem ?

Best regards,
Norbert

14

Hi @norgro2601,

Yes, your are right, that's the problem. We always take "Task" as a default. Because your project does not have the "Task" option as an issue type you get a "400 - Bad request". As a temporary solution, I would suggest creating a project that supports the "Task" issue type. I will bring that to my team and discuss possible solutions. As a user, what would be ideal for you?

Thank you for finding this one.

Best,
Christos

15

Hi @christos.nasikas,

no, using another project with issuetype "Task" is no solution, because we're controling too much in Jira based on the issuetype. And nobody will change that manually on each new case.
At the moment, we use Jira actions in Watcher, beside the issuetype we currently also set priority, labels and environment from the fields available in the Jira action in Watcher.

Regarding UI, it must be possible to set the issuetype in the SIEM case, on the screen it could be placed near to the Tags field, would make sense to me. By the way, I could think of mapping the Tags field from the SIEM case to the Jira labels field. When I look at the SIEM Action API docs, this field is not mapped, right?

I could think of more useful functionality in the create-case action. The most important missing function for us would be the link-issue function from the Jira API. We use this a lot in Jira, actually we are linking new cases manually in Jira. This would be a big improvement for us in a future release update.

Best regards,
Norbert

16

Hi @norgro2601,

Sorry for the late reply. Thank you for your feedback! It is very valuable. I brought it to my team and we put it to our backlog. Unfortunately, for the moment you cannot create issues that do not support the "Task" issue type.

Best,
Christos

17

Hi @christos.nasikas,

one addition regarding the issuetype. We've discussed this again, and we think it would be sufficient to set the issuetype in the connector settings, we probably will not us multiple issuetypes in a Jira project. Maybe this is much easier to implement than to have it in the single case.

Best regards,
Norbert

18

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.

19

@norgro2601

FWIW, this PR adds the support for issue types for Jira.

1 Like