Yeah, you're definitely better off using SSL certs, then you get authentication
at a connection level for the entire stream, rather than having to pay the cost
for verifying the HMAC signing of every single message separately.
-r
On 07/30/2015 10:55 AM, Timur Batyrshin wrote:
Hi,
Thanks, much clearer now!
Actually I was going to get some kind of easy authentication inside SSL
connections without hassle of keeping own CA for SSL-based
authentication to work.
If this signed output is not supported then I’ll take a closer look into
using SSL certs.
Thanks,
Timur
On 30 Jul 2015 20:49:02, Rob Miller <[email protected]> wrote:
------------------------------------------------------------------------
Heka supports signed messages so that it can be possible to send
messages containing control commands into a running Heka server, and
that server can know that the control message came from a trusted
source. This is the method used by the `heka-sbmgr` command to
inject sandboxes into a running Heka instance, provided that
instance has been correctly configured to support this feature. What
do you want to use signed messages for? I haven't yet heard of a use
case outside of the "control message" one that wouldn't be better
handled by a different strategy, such as TLS with client certs.
Anyway, the message signing is implemented in the stream framing
(see
http://hekad.readthedocs.org/en/dev/message/index.html#stream-framing).
You can generate signed messages in Go code, by creating a
MessageSigningConfig struct
(https://github.com/mozilla-services/heka/blob/dev/message/message.go#L52)
and passing that to the client package's NewProtobufEncoder function
(https://github.com/mozilla-services/heka/blob/dev/client/encoders.go#L42).
Any calls to EncodeMessageStream will then give you your message in
a correctly signed frame. Unfortunately there's no support for doing
this from within Heka right now. Any output can support using the
Heka message framing during the encoding process (see `use_framing`
option described here
http://hekad.readthedocs.org/en/dev/config/outputs/index.html), but
this always passes `nil` in as the signing config
(https://github.com/mozilla-services/heka/blob/dev/pipeline/plugin_runners.go#L1616).
It would technically be possible to add support for providing
signing information in the TOML config so that encoded messages are
signed, but, again, when you're dealing with an entire stream, there
are more efficient (and more widely used) mechanisms for achieving
security, so that's not at all high on our priority list. Anyway,
hope this helps, -r On 07/30/2015 10:08 AM, Timur Batyrshin wrote: >
Hi, > > Is there way for heka to emit signed messages? > I’ve seen
some references for that in client libraries but didn’t find >
anything in Heka docs. > > Thanks, > Timur > > > > >
_______________________________________________ > Heka mailing list
> [email protected] > https://mail.mozilla.org/listinfo/heka >
_______________________________________________
Heka mailing list
[email protected]
https://mail.mozilla.org/listinfo/heka