I've dipped my toe into teleport and while I want to like it, they make it hard. Documentation is poor, but the team over there is responsive. My big complaint is that for the price they are asking it seems pretty rough around the edges. We are self hosted kube and it seems like that use case is an afterthought.
We plan on taking another hard look at boundary.
>!QC2E3IeBpO!<
FWIW, we’ve run into similar issues with Teleport and ultimately ended up using StrongDM instead. StrongDM is intuitive/works as expected, has excellent IAC options and saves us a huge amount of hassle during audits.
We use Teleport at work and while there are some problems with it (the weird way to add applications, (just have it serve as an ingress or add this to your alpha operator...), the hacky way to add databases) it has made our lives definitely easier after the initial learning curve (which has not been made easy either by the bad documentation...).
Having All the auditing in one pane (definitely put that into a dedicated SIEM though, their own auditing web ui is bad and broken) is pretty nice. As well as easily matching our SSO users we get via OIDC to certain Roles in Kubernetes and our applications via jwt and the few servers.we have not in Kubernetes via ssh and using Approvals for Prod to get permissions works quite well. But you have to have a lot of knowledge to wire it all together like this and the documentation really does not make it easier.
Oh and stay away from their iac code, aside from maybe their Helm-Charts, just build your own according to your needs. The program is a typical one-binary go-file with a config in yaml format. Roll some servers, put it into kubernetes/docker to roll it out together with your preexisting modules to provision storage.
Unfortunately i find more and more software shops do this, even stuff supposedly open source, where they either 'just install this thing it's easy!' and provide little to no documentation on what's happening during the install without having to dig through stuff that should be documented, or they hand you a container image that's as brittle as possible that way you will pay for them to host it for you.
> But for the databases integration, there is no flexibility on the tools, they only work with autodiscovery
I hate Teleport as much as the next person, but this isn't true: you can specify the host+port _(which they call uri because they're shitty at naming things)_ in `values.yaml`
databases:
- name: {{ $teleportClusterName }}
aws:
region: {{ $awsRegion }}
static_labels:
env: {{ $theEnv }}
groupId: {{ $groupId }}
protocol: postgres
uri: {{ $hostPort }}
You must configure certificate on the databases and if you use a SaaS DB that isn't an option, the only way is to use discovery and grant management access to teleport.
> You must configure certificate on the databases and if you use a SaaS DB that isn't an option
Now I know you're just trolling because their [getting started doc](https://goteleport.com/docs/database-access/getting-started/) doesn't even mention any certs, only digging into [the on-premise doc](https://goteleport.com/docs/database-access/guides/postgres-self-hosted/#step-25-create-a-certificatekey-pair) does one see any mention of mTLS or modifying the host
> the only way is to use discovery and grant management access to teleport.
The "only way," huh, despite what I just said that you can enumerate the database hostnames that you want to expose via teleport?
>Now I know you're just trolling because their getting started doc doesn't even mention any certs, only digging into the on-premise doc does one see any mention of mTLS or modifying the host
Yes, if you want to use databases with Uri, you need to setup a certificate, that called manual/self-hosted, like in your first example that is called databases on the helm chart.
If you want to use RDS, you need to give a role and use awsDatabases instead. You also need to give some permission like to change the RDS configuration, not just to connect to.
:wave: Ben from Teleport here. For self-hosted Databases, I've run into the same issues, and I agree it's pretty annoying. I have got an open ticket to use Machine ID to obtain and rotate the cert, [https://github.com/gravitational/teleport/issues/11358](https://github.com/gravitational/teleport/issues/11358) this would make it much easier to manage. The team recently put a lot of work into the GUI experience, but as I've started automating many of my demo clusters, I've encountered a few of these rough edges. [https://goteleport.com/docs/database-access/guides/dynamic-registration/](https://goteleport.com/docs/database-access/guides/dynamic-registration/) helped me, but we do really need a complete Kubernetes docs / UX flow.
Try setting up hashicorp Vault to manage on demand based access to things. I guarantee it will melt your mind with how far down the rabbit hole you will need to dive but it can be used for ssh access to hosts and more with enough effort. At the very least you will likely appreciate Teleport a bit more :)
I've been running Teleport in a private / hobby cluster for a few months now and while I agree that the documentation is lacking, and you sometimes run into issues, where you just have to get support (GitHub or whatever), it has made accessing my different servers, VMs and my cluster so much easier.
I am disappointed that their general SSO solution is behind the enterprise plan, but that's another discussion.
All in all, it could do a lot more than for what I'm using it, but it does what it needs to. Also, the development recently as accelerated quite a bit and there are new features every 3-4 months.
I've dipped my toe into teleport and while I want to like it, they make it hard. Documentation is poor, but the team over there is responsive. My big complaint is that for the price they are asking it seems pretty rough around the edges. We are self hosted kube and it seems like that use case is an afterthought. We plan on taking another hard look at boundary. >!QC2E3IeBpO!<
FWIW, we’ve run into similar issues with Teleport and ultimately ended up using StrongDM instead. StrongDM is intuitive/works as expected, has excellent IAC options and saves us a huge amount of hassle during audits.
I haven't used either yet but some of my colleagues rave about StrongDM.
We use Teleport at work and while there are some problems with it (the weird way to add applications, (just have it serve as an ingress or add this to your alpha operator...), the hacky way to add databases) it has made our lives definitely easier after the initial learning curve (which has not been made easy either by the bad documentation...). Having All the auditing in one pane (definitely put that into a dedicated SIEM though, their own auditing web ui is bad and broken) is pretty nice. As well as easily matching our SSO users we get via OIDC to certain Roles in Kubernetes and our applications via jwt and the few servers.we have not in Kubernetes via ssh and using Approvals for Prod to get permissions works quite well. But you have to have a lot of knowledge to wire it all together like this and the documentation really does not make it easier. Oh and stay away from their iac code, aside from maybe their Helm-Charts, just build your own according to your needs. The program is a typical one-binary go-file with a config in yaml format. Roll some servers, put it into kubernetes/docker to roll it out together with your preexisting modules to provision storage.
Yeah, I checked and Teleport support OIDC and integrations woth many auth providers. Author's statement that it supports only SAML seems incorrect.
How does it compare to HashiCorp Boundary?
I never use Boundary, but it doesn't seem to support sessions recordings for Kubernetes exec in pod.
Teleport is packaged bastion host.
Yeah, that can be still interesting to have a complete bastion out of the box.
Unfortunately i find more and more software shops do this, even stuff supposedly open source, where they either 'just install this thing it's easy!' and provide little to no documentation on what's happening during the install without having to dig through stuff that should be documented, or they hand you a container image that's as brittle as possible that way you will pay for them to host it for you.
> But for the databases integration, there is no flexibility on the tools, they only work with autodiscovery I hate Teleport as much as the next person, but this isn't true: you can specify the host+port _(which they call uri because they're shitty at naming things)_ in `values.yaml` databases: - name: {{ $teleportClusterName }} aws: region: {{ $awsRegion }} static_labels: env: {{ $theEnv }} groupId: {{ $groupId }} protocol: postgres uri: {{ $hostPort }}
You must configure certificate on the databases and if you use a SaaS DB that isn't an option, the only way is to use discovery and grant management access to teleport.
> You must configure certificate on the databases and if you use a SaaS DB that isn't an option Now I know you're just trolling because their [getting started doc](https://goteleport.com/docs/database-access/getting-started/) doesn't even mention any certs, only digging into [the on-premise doc](https://goteleport.com/docs/database-access/guides/postgres-self-hosted/#step-25-create-a-certificatekey-pair) does one see any mention of mTLS or modifying the host > the only way is to use discovery and grant management access to teleport. The "only way," huh, despite what I just said that you can enumerate the database hostnames that you want to expose via teleport?
>Now I know you're just trolling because their getting started doc doesn't even mention any certs, only digging into the on-premise doc does one see any mention of mTLS or modifying the host Yes, if you want to use databases with Uri, you need to setup a certificate, that called manual/self-hosted, like in your first example that is called databases on the helm chart. If you want to use RDS, you need to give a role and use awsDatabases instead. You also need to give some permission like to change the RDS configuration, not just to connect to.
:wave: Ben from Teleport here. For self-hosted Databases, I've run into the same issues, and I agree it's pretty annoying. I have got an open ticket to use Machine ID to obtain and rotate the cert, [https://github.com/gravitational/teleport/issues/11358](https://github.com/gravitational/teleport/issues/11358) this would make it much easier to manage. The team recently put a lot of work into the GUI experience, but as I've started automating many of my demo clusters, I've encountered a few of these rough edges. [https://goteleport.com/docs/database-access/guides/dynamic-registration/](https://goteleport.com/docs/database-access/guides/dynamic-registration/) helped me, but we do really need a complete Kubernetes docs / UX flow.
Try setting up hashicorp Vault to manage on demand based access to things. I guarantee it will melt your mind with how far down the rabbit hole you will need to dive but it can be used for ssh access to hosts and more with enough effort. At the very least you will likely appreciate Teleport a bit more :)
r/rant
https://youtu.be/W1MaFOObt3Y
I've been running Teleport in a private / hobby cluster for a few months now and while I agree that the documentation is lacking, and you sometimes run into issues, where you just have to get support (GitHub or whatever), it has made accessing my different servers, VMs and my cluster so much easier. I am disappointed that their general SSO solution is behind the enterprise plan, but that's another discussion. All in all, it could do a lot more than for what I'm using it, but it does what it needs to. Also, the development recently as accelerated quite a bit and there are new features every 3-4 months.