Hello Team,
as described in this GH issue: TLS client auth, handshake error 402 · Issue #3455 · sensu/sensu-go · GitHub
I’d like to use TLS authentication for my sensu agents.
Is there any working TLS auth client config so I can take a look?
As workaround I currently let sensu agents talk with the backend through SSH tunnels.
Best,
-f
What have you already tried? Please include links to gists and/or code blocks (if relatively small)
backend certificate CN match backend DNS name (FQDN replaced with xxx)
backend and agent TLS certs generated with easy-rsa CA
agent logs:
Dec 7 15:46:56 v2 sensu-agent[6891]: {“component”:“agent”,“level”:“info”,“msg”:"connecting to backend URL “wss://xxx:8081"”,“time”:“2019-12-07T15:46:56+01:00”}
Dec 7 15:46:56 v2 sensu-agent[6891]: {“component”:“agent”,“header”:“Accept: application/octet-stream”,“level”:“debug”,“msg”:“setting header”,“time”:“2019-12-07T15:46:56+01:00”}
Dec 7 15:46:56 v2 sensu-agent[6891]: {“component”:“agent”,“error”:“handshake failed with status 402”,“level”:“error”,“msg”:“reconnection attempt failed”,“time”:“2019-12-07T15:46:56+01:00”}
Tell us about your setup, this should include OS, version of Sensu, version of Sensu components (redis, rabbitmq), plugin versions (if applicable), anything special about your setup such as an airgapped network or strict ACLs
Sensu version used (sensuctl, sensu-backend, and/or sensu-agent): both sensu-backend and sensu-agent version 5.15.0, build 13884593ee08a7f25d7f66a8b71da61c529de014, built 2019-11-19T20:18:33Z
sensu-backend and sensu-agent on the same machine
Installation method (packages, binaries, docker etc.): deb packages through APT
Operating System and version (e.g. Ubuntu 14.04): Debian bullseye/sid, kernel 5.3.0-2-amd64
Hi @calebhailey thanks for your reply.
I checked the video and changed the config accordingly, now it seems working.
Nevertheless, I’m not 100% happy with this config, let me explain why.
sensu-go TLS config is a sort of “on-off scenario”: enabling it is true for all sensu components, this is a no-sense for me.
dashboard http only is fine if bind to localhost and behind a nginx-like reverse proxy, the same for API service.
Old sensu (core version) let me securing just agent to backend communications leveraging on RabbitMQ native mechanisms, this seems impossible in this new version.
Last but not least:
old sensu did certificate authentication + verification for clients; here clients talk TLS but without specifing any client certificate so I’ve some questions:
is it true I cannot control which clients are connected to my sensu infrastructure due to lack of authentication?
(worst) is sensu agent tls authentication available for commercial version only?
@franz82 I’m glad you were able to get it working. There’s quite a bit to unpack in your response, but let me try to address each of your questions/comments:
"I’m not 100% happy with this config, let me explain why. sensu-go TLS config is a sort of “on-off scenario”: enabling it is true for all sensu components, this is a no-sense for me.
The Sensu Go backend provides separate TLS configuration for the API & Transport (via --key-file and --cert-file), separate from the dashboard (via --dashboard-key-file and --dashboard-cert-file), in case you need separate certificates for the agent-backend connection and dashboard.
"Old sensu (core version) let me securing just agent to backend communications leveraging on RabbitMQ native mechanisms, this seems impossible in this new version."
It is absolutely true that RabbitMQ enabled certain configuration possibilities including transport security - but it was also a heavy external dependency that prevented many potential users from adopting Sensu. We like the trade off of Sensu Go’s new built-in transport for its ease of use, scalability, and because it lets us offer built-in support for TLS and certificate-based auth.
Best of all, because Sensu Go’s built-in transport is based on websockets, you can achieve the same (if not arguably better) configurations as RabbitMQ using third-party components; e.g. you can proxy and secure Sensu websockets traffic using NGINX (or another HTTP proxy that supports websockets - this even includes various proxies offered by your cloud provider, such as AWS ALBs and NLBs). We think this is a net improvement over Sensu Core for a bunch of reasons, including the fact that there are an order of magnitude more people with experience proxying HTTP traffic with NGINX than there are people who are comfortable managing RabbitMQ.
Again, this is all possible with Sensu Go, it’s just not necessary anymore because we give you all of that same functionality out-of-the-box now (and free up to your first 100 nodes).
"is it true I cannot control which clients are connected to my sensu infrastructure due to lack of authentication? (worst) is sensu agent tls authentication available for commercial version only?"
In Sensu Go every agent must authenticate to the backend (unlike Sensu Core which did not offer a built-in RBAC/auth mechanism). By default they will do this using a username and password. If you wished to tightly control which agents are allowed to connect to the backend, you could create unique agent users, though that could become quite burdensome to manage if you have a lot of agents and no SSO. See the sensu-agent start flags for --user and --password (also configurable via the agent.yaml file).
We do offer a built-in alternative solution to this approach in the commercial distribution of Sensu Go via certificate-based authentication. This adds another layer of optionality where you can choose to use a single agent user with a single shared key, a single shared agent user with unique keys per agent. or unique users per agent - each with a unique key.
Bonus: our certificate-based auth solution also supports external PKI and CRL services, so if you already have enterprise certificate management infrastructure in-house, Sensu should be compatible with it.
In conclusion, we think it’s possible to achieve the same or better configurations with Sensu Go as you could with Sensu Core. The major differences are that now you aren’t FORCED to use heavy third-party tooling like RabbitMQ to do so. And, if you prefer the OSS version of Sensu, you can achieve all the same results RE: certificate auth/etc using third-party tooling – it’s just NGINX now instead of RabbitMQ.
have you seen the official documentation on certificate auth for the Sensu Agent?
