Issue creating case from Dev Panel

AceVla · August 25, 2023, 7:43pm

We are creating a case in the dev panel in Elastic, here is the code:

POST api/cases
{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": [ "tag 1" ],
  "connector": {
    "id": "none",
    "name": "none",
    "type": ".none",
    "fields": null
    
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "(user"
}

It's returning this but we can't find it anywhere:

#! [types removal] Specifying types in document index requests is deprecated, use the typeless endpoints instead (/{index}/_doc/{id}, /{index}/_doc, or /{index}/_create/{id}).
{
  "_index" : "api",
  "_type" : "cases",
  "_id" : "(ID)",
  "_version" : 1,
  "result" : "created",
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "failed" : 0
  },
  "_seq_no" : 14,
  "_primary_term" : 1
}

Is there somewhere we aren't looking? it says the case has been created successfully but it's not displayed anywhere.

RylandHerrick · August 25, 2023, 8:30pm

Hi @AceVla!

Judging from your description, it looks like you're trying to use the cases API to create a case manually; is that correct?

If so, you're very close . While you can exercise this API via kibana's dev tools, you need to use the kbn: prefix to make that clear to dev tools:

POST kbn:api/cases

Without that, dev tools will assume you're querying elasticsearch directly, which looks to be what's happened here: it parsed your request as a creation call to the api index, with cases being parsed as a (deprecated) type specifier for the document; the JSON body, then, was parsed as the fields to be indexed into the api index.

Please let me know if that addresses your issue, and have a good day!

AceVla · August 28, 2023, 3:37pm

I corrected the code and ran into a different error, I attempted to correct it and got a 200 message but still no visible case in the security cases.

Here is the simple kbn:api/cases post

POST kbn:api/cases
{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": [ "tag 1" ],
  "connector": {
    "id": "(ID)",
    "name": "My connector",
    "type": ".jira",
    "fields": {
      "issueType": "10006",
      "priority": "High",
      "parent": null
    }
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "cases"
}

It resulted in this error

{
  "error" : {
    "root_cause" : [
      {
        "type" : "invalid_index_name_exception",
        "reason" : "Invalid index name [kbn:api], must not contain ':'",
        "index_uuid" : "_na_",
        "index" : "kbn:api"
      }
    ],
    "type" : "invalid_index_name_exception",
    "reason" : "Invalid index name [kbn:api], must not contain ':'",
    "index_uuid" : "_na_",
    "index" : "kbn:api"
  },
  "status" : 400
}

By changing the : to a / resulted in a success however, this case is still not visable

POST kbn/api/cases
{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": [ "tag 1" ],
  "connector": {
    "id": "(ID)",
    "name": "My connector",
    "type": ".jira",
    "fields": {
      "issueType": "10006",
      "priority": "High",
      "parent": null
    }
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "cases"
}

Resulting in this message

#! [types removal] Specifying types in document index requests is deprecated, use the typeless endpoints instead (/{index}/_doc/{id}, /{index}/_doc, or /{index}/_create/{id}).
{
  "_index" : "kbn",
  "_type" : "api",
  "_id" : "cases",
  "_version" : 5,
  "result" : "updated",
  "_shards" : {
    "total" : 2,
    "successful" : 2,
    "failed" : 0
  },
  "_seq_no" : 4,
  "_primary_term" : 1
}

Thank you for the assistance

RylandHerrick · August 28, 2023, 4:01pm

Hey @AceVla , what version of kibana are you using? The ability to exercise kibana APIs via Dev Tools was added in 8.3, so if you've got an earlier version that might explain the behavior here.

Either way, you should always be able to exercise the cases API with your HTTP client of choice (with appropriate authentication); doing that might help diagnose something that's missing, too, if you're 8.3+.

AceVla · August 28, 2023, 4:05pm

Sorry I forgot to list our version, we are using 7.17. We are using the dev tools to attempt to troubleshoot an issue with the HTTP client. Do we still need the "kbn:" for the HTTP client?

AceVla · August 28, 2023, 4:09pm

This is the code for the HTTP in putty.

curl -k -H "Authorization: ApiKey (key)" -X POST "https://(IP)/api/cases" -H 'kbn-xsrf: true' -H 'Content-Type: application/json' -d'
{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": [ 
	"tag 1" 
],
  "connector": {
    "id": "none",
    "name": "none",
    "type": ".none",
    "fields": null
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "(owner)"
}
'

RylandHerrick · August 28, 2023, 4:19pm

Do we still need the "kbn:" for the HTTP client?

Nope, that's specific to the Dev Tools feature.

We are using the dev tools to attempt to troubleshoot an issue with the HTTP client.

If you can share the issue and/or the error, we're happy to try and help!

AceVla · August 29, 2023, 6:01pm

Here is the error

{"statusCode":401,"error":"Unauthorized","message":"[security_exception: [securi                                                                                                                                                             ty_exception] Reason: unable to authenticate with provided credentials and anony                                                                                                                                                             mous access is not allowed for this request]: unable to authenticate with provid                                                                                                                                                             ed credentials and anonymous access is not allowed for this request"}

The acc that this is being sent from has admin access and I don't think credential sign ins work with the cases field so I'm not sure how to make it not-anonymous.

AceVla · August 29, 2023, 7:20pm

Notably the owner has superuser permissions and the API has full access as well so I'm confused why the owner doesn't have the permissions it needs.

RylandHerrick · August 30, 2023, 2:13am

@AceVla both the error and status code indicate that your API key is not valid. Was this key created through the normal creation flow? Can you verify that it's still valid and active? The Stack Management > API Keys page should be able to answer this.

Other things that you might consider in troubleshooting:

Exercising an unauthenticated kibana API (e.g. /api/status) to validate that your curl command is otherwise correct
Using Basic HTTP Authentication to validate that the user is in fact authorized for Cases, and to validate the Cases request (independent of API key authentication).

AceVla · August 30, 2023, 4:22pm

The API key is active and has no restrictions on its permissions as we are using it in the test environment before production.

The user is a Superuser

Is the path incorrect? Is there more that I need to add apart from the IP, port and api/cases?

RylandHerrick · August 30, 2023, 6:14pm

The API key is active and has no restrictions on its permissions as we are using it in the test environment before production.

Does this mean that you're using the same key in two environments? Which environment are you encountering the 401? Does it work as expected in the other environment?

Can you please share details from the API keys page as shown here?

Is the path incorrect?

It looks to be correct, unless you're working in a space other than the default one; in that case you'd hit /s/{SPACE_ID}/api/cases.

There are a few other things that might be happening here, but the 401 response (as opposed to a 403 or a 404) indicates that that API key is not valid, as opposed to the wrong permissions or route.

Is this a cross-cluster API key? Are you using the key in the same instance in which it was created? Can you try creating a new user with the Cases -> All permission, and create/use an API key on their behalf?

AceVla · August 30, 2023, 7:30pm

The API key was created on the elastic server through the browser and I copied the 64 bit key into the curl request which is running through a putty server. Do I need to create the API on the putty server itself?

This code is the one running through the Putty Server

curl -k -X POST "https://(IP)/api/cases" \
-H "Authorization: ApiKey (API key)" \
-H 'kbn-xsrf: true' \
-H 'Content-Type: application/json' \
-d '{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": ["tag 1"],
  "connector": {
    "id": "none",
    "name": "none",
    "type": ".none",
    "fields": null
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "(username)"
}'

This is the 'restrictions of the API key

{
  "superuser": {
    "cluster": [
      "all"
    ],
    "indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "all"
        ],
        "allow_restricted_indices": true
      }
    ],
    "run_as": [
      "*"
    ]
  }
}

RylandHerrick · September 6, 2023, 4:32pm

The API key was created on the elastic server

Was this API key created in elasticsearch itself (a service API key), as opposed to through kibana (a kibana API key)? You can receive such an error in this case, as kibana doesn't know anything about the elasticsearch service key. This issue is another example of that.

If that's not the case, I would reiterate trying other permutations to narrow down the issue:

Can you exercise the Cases API with another authentication method?
Can you exercise another kibana API (e.g. reading cases)?

FYI there is also a page for Cases prerequisites. It wasn't clear whether you were trying to automate some existing cases workflows, or starting to use cases for the first time, but that page might prove helpful either way.

AceVla · September 11, 2023, 4:28pm

My apologies for my rudimentary answer, I'm still quite new to Elastic overall. I believe I made the API key in Kibana under the security tab. The user who is trying to create these cases is me who has superuser privileges. The overall goal is to create a case that is visible in the https://(IP)/app/security/cases to help automate a workload that is being done manually as of now. I'm not sure if you can get to the cases API using another method, to me it seems like API keys are the only way to do it. The API key in question that is in the stack management section is active also with full permissions.
The code itself is being put onto a putty server

curl -k -X POST "https://(IP)/api/cases" \
-H "Authorization: ApiKey (API key)" \
-H 'kbn-xsrf: true' \
-H 'Content-Type: application/json' \
-d '{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": ["tag 1"],
  "connector": {
    "id": "none",
    "name": "none",
    "type": ".none",
    "fields": null
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "(user)"
}'

{"statusCode":403,"error":"Forbidden","message":"Unauthorized to create case with owners: \"(user)\""}

It should have all the case prerequisites because for now the API key and the user in question have permission to do anything.

RylandHerrick · September 11, 2023, 7:34pm

Hey @AceVla! No apologies necessary, thanks for providing the additional info!

That 403 response is new! Can you explain what changed from your original situation (with the 401 response) to cause this new behavior?

In terms of alternate methods of authentication: you should be able to use Basic authentication as an alternative to the API key. Details can be found here; tools like curl and Postman can generate that header automatically from your username/password. This will bypass the token entirely, and perform the request as the user themselves (as opposed to a snapshot of the user's roles/permissions in the case of the API token). Whether or not that method works should give us insight into where the problem is, here.

One more question in the meantime: is this user able to perform these cases workflows manually in the kibana UI?

AceVla · September 12, 2023, 6:19pm

As of now it seems that resetting the API key entirely was what fixed the issue. I tried basic authentication as seen here. With the same error.

curl -k -X POST "https://(IP)/api/cases" \
-H "Authorization: Basic $(echo -n '(username:password)' | base64)" \
-H 'kbn-xsrf: true' \
-H 'Content-Type: application/json' \
-d '{
  "description": "A case description.",
  "title": "Case title 1",
  "tags": ["tag 1"],
  "connector": {
    "id": "none",
    "name": "none",
    "type": ".none",
    "fields": null
  },
  "settings": {
    "syncAlerts": true
  },
  "owner": "(user)"
}'

{"statusCode":403,"error":"Forbidden","message":"Unauthorized to create case with owners: \"(user)\""}

If the user tries to create the case manually through the Kibana UI then the case is able to be created without issue.

system · October 10, 2023, 6:19pm

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