search

threatstack / threatstack-ansible

Ansible for installing Threatstack Agent
https://www.threatstack.com
MIT License
23 stars 16 forks source link

Post install configuration with tsagent version 2 #46

Closed stevenscg closed 5 years ago

stevenscg commented 5 years ago

Similar to https://github.com/threatstack/threatstack-ansible/issues/34, we would like to bake the agent into AMIs and possibly with some configuration for the v2 tagents.

The helpdesk article says to run the tsagent setup --deploy-key= command during provisioning. This makes sense.

Will this command ensure that the tagent is both started and enabled at boot via systemd? This role does it after the agent is setup and restarted and after waiting.

Is the tsagent --config option and support for the config file from the 1.x series going away or already gone? I can also see a security benefit to not having the config file or deploy key ever on disk. We might prefer to deploy a config file with the AMI build and non-sensitive info in some cases if that is going to continue to be supported.

ghost commented 5 years ago

Will this command ensure that the tagent is both started and enabled at boot via systemd?

In 2.0, the behavior for tsagent setup is a little different. tsagent start(or systemctl start threatstack on platforms with systemd) must be run afterwards to actually start the agent, whereas in 1.x the cloudsight setup command both configured and started the agent. The agent is installed as a service registered with systemd on package install if systemd is present IIRC.

Is the tsagent --config option and support for the config file from the 1.x series going away or already gone?

There is no longer support for a config file. Configuration is done via tsagent config -set key1 value1 key2 value2 keyx valuex The config does exist as a file, but it is encrypted and contains the unique identifier of the agent. So baking it into an AMI would be a bad idea because it would cause mutliple agents to share an identity, which ~might~ definitely will break stuff.

IIRC when we released 2.0 this info should have been included in documentation. I remember helping draft it, but I don't know when/where it was published to the outside world. Will update with link if I find out.

stevenscg commented 5 years ago

Thanks @Shplorf. Makes sense to me. I have something that works for us. It might be nice to have those additional steps as part of the role at some point since this is a fairly common deployment pattern.

Seems like there should be 2 distinct phases of installation for the v2 agent. Both can be done by default to match the current behavior. Phase 1 at image build time does the install. Phase 2 at provisioning time does the setup and systemd stuff.

I'll close this issue though.

ghost commented 5 years ago

@stevenscg I think you can use the threatstack_configure_agent parameter to accomplish what you want:

threatstack_configure_agent: # Optionally do not configure the host, just install package