Use external ressourcename as hostname when using dynamic host catalogs

[jwueste]

Hi,

when using dynamic host catalogs, all found hosts are displayed with a name that corresponds to the internal host ID. This ID does not allow any conclusions about the actual resource. The resource name of the detected resource should be used as the name for the automatically generated hosts. Or is it already possible to configure it this way?

Best, Jonas

[talanknight]

Hi Jonas, Thank you for taking the time to submit this issue! Dynamic host catalogs are very new and their functionality is still be discussed and built, so these issues are very helpful for us to consider while moving forward. We do not currently allow automatic assignment of host names, but the external_id field on the host is the unique id from whichever backing service the host was brought in from. Our current plans do include providing more details regarding the resource that we brought into boundary, including its name, possibly through the host's attributes field.

[psypuff]

Thanks for the response Todd.

Is it an internal discussion or is there anything public we can contribute to? I couldn't find anything public so far so here are my thoughts:

• I'm currently trying to see if I can implement Boundary into our existing flow (specifically for SSH atm) while keeping the interface intact as much as possible (most of our devs use ec2grep now).
• Currently it seems like it'll require a lot of shell / jq magics to actually make it happen (to create some kind of an inverted index) since there's no way to natively query Boundary for a specific IP or anything else the aws / azure plugin fetches from the cloud provider.
• Having a Consul integration, as the roadmap suggests, would be awesome (assuming one could ref hosts by service names). Until then, it would be great to have the ability to query Boundary for hosts using IPs / DNS names so we could actually use the SSH ProxyCommand suggestion (with IPs instead of Boundary IDs) or come up with a saner shell alias for our devs.

Thanks

[psypuff]

I realized I overlooked the resource filtering capability. Although it simplifies the process a bit, in order to connect via SSH, a client is still required to:

1. Fetch Scope ID
2. Fetch Host Catalog ID
3. Fetch Host ID
4. Fetch Target ID

I guess what I'm aiming for is a single boundary connect <IP> or boundary connect <service-name> (the latter assumes a Consul integration) that will abstract away the above multiple commands and will verify the client has the correct permission to connect to this host.

Again, I don't know if that's already on your mind / roadmap. Would love to provide more context / ideas if you wish.

Thanks

[xingluw]

Hi @psypuff, thank you for the suggestions, this is something we will discuss more internally and consider adding to our product roadmap!

[japneet-sahni]

@talanknight @xingluw : Do we have any update on this issue. Dynamic host catalogs are nearly unusable via admin console or desktop app, because discovered hosts don't get a human identifiable name.

[RobertSkawinski]

@talanknight @xingluw : Do we have any update on this issue. Dynamic host catalogs are nearly unusable via admin console or desktop app, because discovered hosts don't get a human identifiable name.

Same here for Azure :) +1 for human readable hostnames

[xingluw]

@japneet-sahni @tritonblaster This is something we are considering for our roadmap next year, will keep the ticket open to gauge community interest through upvotes.

[jefferai]

@japneet-sahni to be clear we don't actually assign any name to those hosts currently (but you can name them whatever you want) but we do expose the external ID so at the moment that is a way to correlate the host in Boundary with the host from the cloud. We are looking into expanding that to expose the external resource name.

[hugoghx]

Hello all, my team and I have now started investigating integrating and syncing the various providers' external resource names into Boundary as a whole 🙂

[xingluw]

Hi @jwueste @psypuff @japneet-sahni @RobertSkawinski, do you care about external/provider description as well? Or only the external/provider name?

If you do want the external/provider description in Boundary, how do you identify it on the provider side? Would it be by using tags on the resource?

[RobertSkawinski]

Hi @xingluw, for Azure it would be great to map the external resource name with the targetname / hostname in Boundary.

A description field is (for me) optional. In Azure resources do not have a description. If you need something, you could for example use tags to get values inside the description field.

[xingluw]

Hi everyone, this has been resolved in our latest 0.13 release. For more information, see the 0.13 release notes and changelog.