Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HashiCorp Boundary

hashicorp.com

Post reply on HN
Print view View original

161–170 of 171 posts

Re: HashiCorp Boundary

#161

Post by jefferai »

3np wrote: post #152
mitchellh wrote: post #11

Hello HN! I'm the founder of HashiCorp. I'm excited to see Boundary here! I want to note a few things about Boundary, why we made it, why it is different than other solutions in the space, etc. * Boundary is free and open source. Similar to when we built Vault, we feel like the solution-space for identity-based security is too commercialized. We want to provide access to this type of security to a broader set of peop…

From a first look this is really exciting. And cool to see you here on HN! I live your positioning and how you’re first and foremost building FOSS software and tools that you leverage on, as opposed to building a commercial offering that you then release software for. It’s a vital distinction that sets you apart from eg Google. Let’s say you have an org that’s doing the whole Consul/Nomad/Vault thing, and starting to…

In an immediate sense you could have targets point to services handled by Connect, so you'd have client -> Boundary worker -> local Connect entrypoint -> end service.

We'll be looking more closely at other integration possibilities going forward!

Re: HashiCorp Boundary

#162

Post by jefferai »

victorhooi wrote: post #151
pliu wrote: post #106

Earlier quoted context omitted.

It would be interesting if the networking model for the end targets could also be inverted, so that an agent (or something) on the end target could make an outbound connection to establish a reverse tunnel to the proxy that user connections could then be sent over. The use case I'm thinking of is for IoT or robotics, where you have devices you want to manage being deployed into remote networks that you don't have muc…

Second this! CloudFlare Access allows this, using the cloudflared daemon, which acts as a reverse proxy. It essentially means the endpoint can be closed off to incoming connections from the internet, and you don't need to maintain various firewall whitelist (and hope they don't go out of sync) Is something like this on the roadmap for Boundary?

Without committing to any specifics, I'll say that we are very aware of use-cases where a daemon on the end host can provide enhanced benefits.

As you can imagine we did quite a bit of research with our existing users/customers while working on the design of Boundary. One thing we heard almost universally was "please don't require us to install another agent on our boxes". So we decided to focus initially on transparent use cases that only require running additional nodes (Boundary controller/worker) without requiring additional software to be installed/secured/maintained on your end hosts.

> the endpoint can be closed off to incoming connections from the internet, and you don't need to maintain various firewall whitelist

If you think about this a bit differently, a Boundary worker is also acting as a reverse proxy gating access to your non-public network resources. You can definitely use Boundary right now to take resources you have on the public Internet, put them in a private-only subnet or security group, and then use a Boundary worker to gate access. It's simply a reverse proxy running on a different host rather than one running on the end host. You wouldn't _need_ to add a firewall to ensure that only Boundary workers can make incoming calls to the end hosts, it's simply defense in depth.

Re: HashiCorp Boundary

#163

Post by jefferai »

TheGuyWhoCodes wrote: post #133
mitchellh wrote: post #112

Earlier quoted context omitted.

You can do this already, The `boundary connect ssh` stuff is just a convenience. You can spin up a local boundary proxy to anything and just connect anything that speaks TCP over it. This allows you to use all the tools you just named. A desktop client is on the way, we already have an internal build of parts of it but it requires more work and didn't make it for 0.1.

Thanks for answering. boundary proxy is an ok step but user experience should be streamlined especially if it's for teams and orgs and not just individuals who want to hack scripts but I full understand it's a 0.1 release. Another thing I couldn't find in the docs is support for multiple installations, let's say I have different vpcs (In different accounts) or I have one on-prem installation and one in a cloud how do…

We don't have something natively, but you can control the address via BOUNDARY_ADDR env var or the -addr flag per-call, and you can use -token-name with the CLI to switch between named tokens, which can be sourced from different accounts. Together it'd be pretty easy to write a shell alias to do what you're looking for.

Re: HashiCorp Boundary

#164

Post by sterlinm »

This looks pretty interesting both for some projects at work and for my homelab. I'm a data scientist with an amateur interest in devops so apologies if this is a silly question, but I'm trying to get a sense of the use cases.

Would it make sense to use boundary as a way to manage access to web-based developer environments using an IDP for authentication (e.g. Github, Google, Okta, etc). I'm thinking of tools like JupyterLab/Hub, RStudio Server, etc. Or is that outside the intended scope of Boundary?

Re: HashiCorp Boundary

#165

Post by jlgaddis »

pliu wrote: post #106
jefferai wrote: post #68

Earlier quoted context omitted.

Generally speaking this is designed for accessing your own systems, not the systems of a third party being consumed as a SaaS. That said, any such provider that allows you to restrict the set of IPs allowed to make calls to the service would operate in a Boundary-friendly mode.

It would be interesting if the networking model for the end targets could also be inverted, so that an agent (or something) on the end target could make an outbound connection to establish a reverse tunnel to the proxy that user connections could then be sent over. The use case I'm thinking of is for IoT or robotics, where you have devices you want to manage being deployed into remote networks that you don't have muc…

It seems like using WireGuard on the "end target" to automatically connect to (WireGuard on) the proxy would be an easy workaround.

I did basically the same thing years ago for remote console devices deployed inside various customer networks where I had little or no control over the network. At that time, I used OpenVPN to automatically connect back to our "VPN servers" -- providing access to the device even if it was behind two or three layers of NAT (which, unfortunately, wasn't uncommon!).

Re: HashiCorp Boundary

#166

Post by kodah »

eeZah7Ux wrote: post #160
kodah wrote: post #75

Earlier quoted context omitted.

Man, this really represents the rift in Open Source and Corporate development right now. It seems like there are developers who contribute to Open Source because they like the mission, the impact, and the values. In contrast, there are others who contribute to open source because their job requires or mandates it. Then there's people who have a mix of both. All three have wildly different values and historically corp…

> that referring to HashiCorp (and other) projects as "open source" is a half truth Spot on. Corporate "open source" is often open only in terms of licensing, but not in terms of values. Many companies use tricks to prevent successful forks and keep tight control over the development process.

I can tell you both from an inner source and open source standpoint, executives (more than engineers it seems, but that could just be my friends) have an outright fear of forks.

Re: HashiCorp Boundary

#167

Post by bulatz »

outworlder wrote: post #127
luminousbit wrote: post #62

Personally I’ve been a big fan of strongDM ( https://www.strongdm.com/ ). Lightyears ahead of teleport or any of the other solutions out there. Built for great auditing and zero trust. Best of all it’s multi-protocol. So you can do SSH, SQL, K8s, HTTP all with one access system. Had it in prod for almost two years. Gonna be a long time before hashicorp or anyone else can catch up with the level of depth.

> Best of all it’s multi-protocol. So you can do SSH, SQL, K8s, HTTP all with one access system. Teleport is SSH based so you can tunnel other protocols.

I tried to set up sftp via strongdm hoping it will work since sftp is using ssh, but I failed. It just did not connect

Re: HashiCorp Boundary

#168

Post by jzjzjz »

I'm looking for more clarification on how i can fit this into my Cloudflare ecosystem. Assuming many of your clients are consuming Cloudflare and all of their backbone, security, networking, and remote work services.

Would I just have Boundary authenticate via Cloudflare Access and whatever identity provider Cloudflare One is integrated with and move to the RBAC policy phase of the authentication - is this where i am seeing that additional value from Boundary by having that additional on demand credential rotation to various internal Apps and DBs once i am past the SSO stage? CF One is more of a vertically integrated all in one service addressing all of my other networking and security needs so it's not really going anywhere.

I think you guys could do well to release a Cloudflare integration paper, it might help with traction on on-boarding customers.

Thanks!

Re: HashiCorp Boundary

#169

Post by eeZah7Ux »

kodah wrote: post #166
eeZah7Ux wrote: post #160

Earlier quoted context omitted.

> that referring to HashiCorp (and other) projects as "open source" is a half truth Spot on. Corporate "open source" is often open only in terms of licensing, but not in terms of values. Many companies use tricks to prevent successful forks and keep tight control over the development process.

I can tell you both from an inner source and open source standpoint, executives (more than engineers it seems, but that could just be my friends) have an outright fear of forks.

so?

Re: HashiCorp Boundary

#170

Post by TheFlyingFish »

btgeekboy wrote: post #140
mmettler wrote: post #131

Another company to watch here is Tailscale, which is Wireguard-based: https://tailscale.com/ (disclosure: small Tailscale investor)

I like the people behind Tailscale, but I’ve yet to figure out how they’re different than ZeroTier.

I've tried both. I ended up going with Tailscale because:

- Better throughput overall.

- better NAT holepunching. E.g. ZeroTier gives up entirely with "symmetric NAT" where each outbound connection gets a random source port, but Tailscale has a few extra tricks that it can try (including opening a whole bunch of outbound connections, trying ports at random, and hoping the birthday paradox will kick in, which I think is pretty cool.)

- But most of all, Tailscale didn't suffer from weird intermittent throughput/latency issues between different cloud providers the way that ZeroTier did. Sometimes my machines could talk to each other pretty fast, other times it was clamped down to ~10 MB/s for no apparent reason. Sometimes it only showed up in one direction, sometimes both. I gave up on trying to troubleshoot it when I discovered Tailscale.

That said, I still like ZeroTier a lot and think it's a great project. It also provides a whole LAN layer, with stuff like actual broadcast traffic, for which Tailscale has no equivalent.

Post reply on HN