Would be interesting to pass a tag during enrollment, like Zentral does...

[flaviod]

Hi

Just one idea if not in your radar yet. Zentral uses a very smart way to pass any tag to the tls server during enrollment. Their method is very intelligent and it would expanded like:

--enroll_secret: secret: tag1: tag2: tag3
like example:
--enroll_secret: secret : Linux : Centos : Payment_team : Datacenter-1: Production

So, if we are using some automation, the endpoint can pass one 1 or N tags during enrollment.
Doorman will receive that enrollment string to assign (or create) the correct tags to the system. Avoiding manual intervention moving systems to tags after the enrollment.

Best Regards,

Flavio.

[mwielgoszewski]

Great idea! Should this be a configuration option? Some people may have secrets with colons in them...

[sroberts]

We did this with heroku/windmill and it was highly useful.

[flaviod]

Yes, if this is implemented, it will make easier for any automation and we would be able to use Doorman instead of Zentral (our choice today) as TLS server in my company ;)

Since you control what your server can receive, you can find a way (or better way) to use the --enroll_secret to pass extra information to the server, in our case, we are interested to assign automatically the correct (N tags) to the the end-point. It would make our life much easier. The "enroll_secret" is the only variable that osqueryd has that can use and design this solution.

[mwielgoszewski]

Yep, I understand from the osquery side this is "overloading" the enroll_secret configuration option. What I'm wondering, is whether this should be an opt-in configuration on the doorman side (i..e, don't automatically treat all enroll secrets that are colon delimited as being tagged).

[flaviod]

What I'm wondering, is whether this should be an opt-in configuration on the doorman side (i..e, don't automatically treat all enroll secrets that are colon delimited as being tagged).

I think opt-in (giving options to the users) are always welcome. But I think if you can add this feature to your tool, it would be a good thing since will make life much easier and the adoption of your tool more able to handle automation ;) You probably can implement this feature really fast :)

[flaviod]

The most difficult part of the implementation would be parse the enroll string.. Maybe you could user different characters like "|" "-" "," or something more appropriate

--enroll_secret: secret | "tag 1" | "tag 2" | "tag4" | ...

(Well, I don't know the osquery variable size that osquery uses for enroll_secret)

[mwielgoszewski]

@flaviod okay, just submitted a PR for this. Couple things to note:

• By default, DOORMAN_ENROLL_SECRET_TAG_DELIMITER is None, implying you must configure it to a string in order to actually make use of this feature. This also supports specifying your own delimiter, so you're not restricted to just a colon.
• A maximum of 10 tags can be inherited when a new node enrolls. I believe this to be more than adequate for the time being. Any tags that don't already exist will be automatically created. I want to avoid exposing a DoS by supporting unlimited tags here.
• A node will not inherit any new tags if it has already been enrolled before. (i.e., installing an osquery upgrade... or an API response instructing the node to re-enroll. I may change this behavior in the future).