403 Forbidden Error When Accessing Operate API After Switching from Docker Compose to Kubernetes with Kind and Helm

Camunda 8 Topics
1

I decided to follow your recommendation and switch from the Docker and Docker Compose setup to Kubernetes with Kind and Helm for local development. The new setup starts successfully, and all modules are up and running. I can deploy and start processes using Modeler, open Operate, view the task list, and so on. However, the only issue I’m encountering is that when I try to access the Operate API using a cookie, as I did before with the Docker Compose setup, I receive a 403 Forbidden response. What needs to be done to resolve this?

POST http://localhost:8081/api/login
Content-Type: application/x-www-form-urlencoded

username=demo&password=demo

POST http://localhost:8081/v1/process-definitions/search
Content-Type: application/json

{"size":1000}

Response:

POST http://localhost:8081/v1/process-definitions/search

HTTP/1.1 403 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'; base-uri 'self'; script-src 'self'; script-src-elem 'self' cdn.jsdelivr.net; connect-src 'self' cdn.jsdelivr.net; style-src 'self' 'unsafe-inline' cdn.jsdelivr.net; img-src * data:; block-all-mixed-content; form-action 'self'; frame-ancestors 'none'; frame-src 'self' https:; object-src 'none'; font-src 'self' fonts.camunda.io cdn.jsdelivr.net; worker-src 'self' blob:; sandbox allow-forms allow-scripts allow-same-origin allow-popups
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 20 Aug 2024 16:41:20 GMT
Keep-Alive: timeout=60
Connection: keep-alive

{
  "timestamp": "2024-08-20T16:41:20.115+00:00",
  "status": 403,
  "error": "Forbidden",
  "message": "Forbidden",
  "path": "/v1/process-definitions/search"
}
2

I have just tried it again in a completely different environment with the same result.

Can someone from Camunda quickly install kind and use the Helm chart with the values from this repository? You can do it like this:

helm install camunda-platform camunda/camunda-platform -f camunda-platform-core-kind-values.yaml

Once the installation is complete, get the cookie using the
http://localhost:8081/api/login
endpoint and then try to access
http://localhost:8081/v1/process-definitions/search
as I described above.

You should receive a 403 response.

If that is the case, it means that the current configuration provided by Camunda for kind/Helm does not make sense for local development if you need more than what the Zeebe client offers. In that scenario, you would need to stick with the Docker Compose configuration.

3

Adam, As you mentioned i did create new Camunda 8 Kind environment using Docker Compose and Kind.

Only in Kind, passing cookie as header is mentioned, i Got 403 as you mentioned. Also side by side i tested the same request using Docker Compose environment. There also got a 403 error.

Are you sure it’s broken only in KIND? I am yet to test with Ingress configuration.

4

With Ingress also it’s failing.

image
image1393×123 21.6 KB

Reference Documentation:

5

If you use docker compose setup you need to pass cookie as well,

Request Url: http://localhost:8081/v1/process-definitions/search
Method: POST
Request Headers:
{
  "content-length": "15",
  "accept-encoding": "gzip, deflate, br",
  "cookie": "OPERATE-SESSION=C3BAAF6111B44F744065557FFCB1C932; OPERATE-X-CSRF-TOKEN=b3c2a15f-989d-4ad5-afd8-c6252bfba53d",
  "Accept": "*/*",
  "User-Agent": "Thunder Client (https://www.thunderclient.com)",
  "Content-Type": "application/json"
}
Request Body:
{
  "size": 2
}

then you will get a proper response:

{
  "items": [
    {
      "key": 2251799813685436,
      "name": "C8 Demo Scenarios Simple System Task",
      "version": 1,
      "bpmnProcessId": "c8-demo-scenarios-simple-system-task",
      "tenantId": "<default>"
    },
    {
      "key": 2251799813685506,
      "name": "C8 Demo Scenarios Exception Handling",
      "version": 1,
      "bpmnProcessId": "c8-demo-scenarios-exception-handling",
      "tenantId": "<default>"
    }
  ],
  "sortValues": [
    "2251799813685506"
  ],
  "total": 27
}

The same setup with kind (I use tunnel on port :8181 for Operate to avoid conflicts) ends with 403:

Request Url: http://localhost:8181/v1/process-definitions/search
Method: POST
Request Headers:
{
  "content-length": "15",
  "accept-encoding": "gzip, deflate, br",
  "cookie": "OPERATE-SESSION=C3BAAF6111B44F744065557FFCB1C932; OPERATE-X-CSRF-TOKEN=b3c2a15f-989d-4ad5-afd8-c6252bfba53d",
  "Accept": "*/*",
  "User-Agent": "Thunder Client (https://www.thunderclient.com)",
  "Content-Type": "application/json"
}
Request Body:
{
  "size": 2
}

response:

{
  "timestamp": "2024-08-23T05:23:59.635+00:00",
  "status": 403,
  "error": "Forbidden",
  "message": "Forbidden",
  "path": "/v1/process-definitions/search"
}

I use standard configuration of a cluster with kind as described in the Camunda docs without Ingress or any other modifications.

6

Hey Camunda folks, any updates on this issue? Am I the only one with this problem or is no one using C8 with kind and helm?

7

I have the same issue. In our case it’s a proper k8s with helm.

Interestingly enough, I got it working interactively through swagger, i.e. a plain old browser. Still trying to figure out what’s different between the requests sent by the browser and non-interactive application code.

8

Update: I followed Authentication | Camunda 8 Docs exactly. Got a HTTP 204 with the cookie back from /api/login, but then this fails to be used with the api itself.

Upon closer inspection, I noticed an additional header sent back: “operate-x-csrf-token”. This needs to be sent along with subsequent requests.

This is a documentation failure, but to be honest, this could be considered a bug, since a CSRF token is already set in the Cookie (OPERATE-X-CSRF-TOKEN). The tokens are not the same however, but this might be down to an encoding.

2 Likes
9

@roeme Great, I completely missed that because I was actually blinded by the token in the cookie. Thank you.

10

Just a hint for anyone who may have spent hours like me struggling with this issue: both the header and the cookie must be present in the request; otherwise, you will get a 403 error. It seems the API has some quirks in this regard.

11

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