Open jhudson10x opened 6 months ago
The workaround would be to also consume the main Teleport module as well as the API module - but I'm extremely aware this is a very clunky workaround as that balloons the binary size significantly and creates limitations around compilation.
What you're asking for here is something I've been extremely keen to support in the future - we've recently started doing something very similar to this within the Teleport Kubernetes Operator (it embeds the tbot code and uses that for authentication almost exactly how you describe - https://github.com/gravitational/teleport/blob/master/integrations/operator/embeddedtbot/bot.go) and I'd love to do the same with our other utilities (e.g the Terraform provider).
This feature request is currently blocked by https://github.com/gravitational/teleport/issues/32632
@jhudson10x I'm interested in learning more about your Machine ID / Lambda Use-case. Would you mind sending me an email to ben@goteleport.com so I can ask some follow up questions.
What would you like Teleport to do? Expose
tbot
to the public API so that functions liketbot.New()
in"github.com/gravitational/teleport/lib/tbot"
and the config structs for the tbot in"github.com/gravitational/teleport/lib/tbot/config"
can be called by consumers of the SDK.What problem does this solve? It will make it easy to write self-contained programs that can then be loaded into e.g. AWS Lambda. Example:
This short snippet of code creates a client that connects to the cluster using the cert that comes back from doing a one-shot Machine ID auth.
To get this to build means cloning Teleport, creating a new tool like
tctl
,tbot
, adjusting the Makefile to build the new tool, using the Teleport build process to generate the binary, then pulling it out and stuffing it into a lambda. Being able to programatically configure and invoke Machine ID will make trivial what has been a so-far difficult workflow to implement in CI/CD.I'm not aware of a workaround for this.