Thoughts On A Potential teleport.yaml Configuration Linter

[irishgordo]

Hey there!

Wanted to ping the community/all-y'all-awesome-folks at some thoughts surrounding the possibility of crafting a fairly-flexible teleport-configuration auditor/rules-engine of sorts?

I could see a few use cases, some being related potentially having separate teleport configs needed for separate spots, maybe those configs are source controlled and their are pipelines present to support CI/CD kinda activity surrounding them. Maybe there are others on another team that need to make RFC's to the configuration or something of the like. I had a few better examples in my head but they've disappeared from my memory 😅 tonight.

Just been curious if there has been any thoughts on anyone's radar about something that will audit/allow-for-custom-rules-even/check/advise/warn/etc on /etc/teleport.yaml / teleport.yaml files that represent configuration.

I hashed out a very-extremely-rough-proof-of-concept (I really just was playing around a bit):
https://github.com/irishgordo/teleport-conf-linter
An example personally that I see myself messing up on in configuration, if I didn't review comments, would be the "enabled" YAML property, to me, I fall naturally into a pattern of having things like "enabled" as a boolean style value, either true/false - in that repo, the example of "app_service.enabled" exists. And within the teleport.yaml, I do see the configuration properties supporting either: true|false or yes|no -> separate places - the comments are very helpful and super awesome.

I really dig the comments! Very helpful for the configuration. As teleport expands I could see configuration expanding along the way too. Perhaps a linter could help as the configuration scales out.

Thanks for any thoughts/feedback!

[webvictim]

We have an open issue to address this sort of thing with a teleport configure --test flag, but haven't assigned development time to work on it yet: #5559

I agree that our interchangeable use of truthy values rather than straight true/false throughout our docs is a bit odd. There is even a setting called proxy_checks_host_keys which will fail if it isn't set to the exact string yes or no which I think is a legacy issue.