If using an authmethod with a bearertoken to generate short-lived tokens rather than using static tokens, there is no logic to reauthenticate/rotate this token. Once the TTL passes, the connection manager fails with ACL errors:
2025-12-03T17:40:14.005Z [INFO] consul-dataplane.server-connection-manager: ACL auth method login succeeded: accessorID=...3c
... <10 minute TTL>...
2025-12-03T17:50:14.209Z [ERROR] consul-dataplane.server-connection-manager: connection error: error="rpc error: code = Unauthenticated desc = ACL system must be bootstrapped before making any requests that require authorization: ACL not found"
Since the mesh-init process writes data to the shared volume (/consul/consul-dataplane.json), it would make sense that the dataplane (and healt-sync) containers re-use that data to re-auth. As a workaround on the health-sync, a modified entrypoint to run a loop works..
entryPoint = ["sh", "-c"]
command = ["while true; do timeout -s HUP 5m /bin/consul-ecs health-sync; done"]
but on the dataplane, this will cause unacceptable interruptions.
It look like the token is origially generated in the Run method on line 179 ..
If using an authmethod with a bearertoken to generate short-lived tokens rather than using static tokens, there is no logic to reauthenticate/rotate this token. Once the TTL passes, the connection manager fails with ACL errors:
Since the mesh-init process writes data to the shared volume (/consul/consul-dataplane.json), it would make sense that the dataplane (and healt-sync) containers re-use that data to re-auth. As a workaround on the health-sync, a modified entrypoint to run a loop works..
but on the dataplane, this will cause unacceptable interruptions.
It look like the token is origially generated in the Run method on line 179 ..