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

Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

github.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#31

Post by jmorgan »

alexk wrote: post #17
jmorgan wrote: post #13

Earlier quoted context omitted.

Great point on GRPC having better support for event streaming! We originally built Infra to have a GRPC API, but many users we spoke to didn't yet have load balancers or ingress controllers that supported the GRPC protocol (e.g. one user had to consider upgrading their AWS Load Balancer controller to put Infra behind it). We wanted to remove as many hurdles as possible for teams to deploy Infra in their environments.…

Re: GRPC My bet that you'd migrate to GRPC eventually as you scale :) I like the simplicity of HTTPS/JSON API as well, but it just broke down for us at a certain scale point. Re: Teleport with EKS True, CNCF clusters support mTLS out of the box, but EKS hides the endpoint and does not let you provision CA to trust. You will have to run teleport proxy inside the EKS cluster to translate mTLS to EKS IAM auth. However,…

Thanks! Curious, where did HTTP+JSON break down for you? Was it specifically around audit/event streaming? This would be helpful as we consider building out future updates to Infra, especially considering tools like Kubernetes have put HTTP+JSON APIs the test (at least in their user-facing APIs)

Indeed! EKS + others don't allow custom authentication methods or allow you to use an external CA for the cluster. Running a proxy agent in each cluster makes sense and is similar to how Infra approaches it: I hadn't seen that configuration in your architecture pages!

Have you considered distributing certificates signed by the cluster CA itself (to avoid proxies altogether)? In 1.22 onwards there's a new ExpirationSeconds field when creating a certificate signing request: https://github.com/kubernetes/enhancements/issues/2784 . I imagine this will be supported by all the hosted Kubernetes services - we've been watching this closely.

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#32

Post by speedgoose »

solatic wrote: post #11
jmorgan wrote: post #3

Earlier quoted context omitted.

Thanks for the questions! Vault doesn't have a deep integration to generate credentials for Kubernetes, and Infra plugs in to users' tooling (e.g. kubectl and Kubeconfig) to keep credentials up to date automatically. Infra's different than Teleport in a few ways. Teleport doesn't provide identity provider integrations beyond GitHub (e.g. Okta) in their open source project. They have a different architecture that invo…

As someone who is a big fan of Teleport, sorry, I just don't get it. > Teleport doesn't provide identity provider integrations beyond GitHub (e.g. Okta) in their open source project Right, and if you're a small team (5-10 people, like you're targeting) you don't really need SSO on the infra layer. It's a nice to have, it's best practice, but the truth is, by the time you really need it (enough engineers that account…

SSO on infrastructure is not a must for everyone but it’s a very nice thing to have. Teleport pricing for small teams doesn’t make sense, it’s more expensive than GitHub enterprise that provides SSO, and Infra is very welcome to provide basic features to everyone and not locked behind a “contact us” price.

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#35

Post by mchiang »

speedgoose wrote: post #33

The connector.config.skipTLSVerify=true in the quick start document is a bit scary. A secure setup may be a bit more complex but your product is not targeting beginners, so a correct tls configuration may not scare people away.

thank you for this feedback. We've made several edits to the quickstart to get users started as quickly as possible as proof-of-concept installs either on a test cluster in the cloud or a local cluster.

For the a longer setup: https://infrahq.com/docs/install/install-on-kubernetes

We will definitely better address this in the future. Thank you for pointing this out.

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#36

Post by aequitas »

At first I thought this was a relaunch of Infra App[0], because that project has been stale for a year now since they introduced licensing and has been superseded by Lens feature wise anyways.

This looks very interesting, will give it a try.

[0] https://infra.app

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#37

Post by mchiang »

aequitas wrote: post #36

At first I thought this was a relaunch of Infra App[0], because that project has been stale for a year now since they introduced licensing and has been superseded by Lens feature wise anyways. This looks very interesting, will give it a try. [0] https://infra.app

Thanks for checking out Infra!

Infra App is Jeff and I's passion project when we started. We still patch it for security / bugs. That being said, we've definitely been thinking about how we should maintain / let the rest of the community take it over if there is such an interest. If anyone wants to chat about that, ping me at michael -at- infrahq.com

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#39

Post by jmorgan »

AETackaberry wrote: post #38

What configuration is required to set this up for managed kubernetes (AKS/EKS/GKE)? Do you need to make api server configuration changes?

Hey there! No changes to the api server configuration are required. We've designed Infra around this since AKS/EKS/GKE don't expose the ability to edit api server parameters to users.

Re: Launch HN: Infra (YC W21) – Open-source access management for Kubernetes

#40

Post by AETackaberry »

jmorgan wrote: post #39
AETackaberry wrote: post #38

What configuration is required to set this up for managed kubernetes (AKS/EKS/GKE)? Do you need to make api server configuration changes?

Hey there! No changes to the api server configuration are required. We've designed Infra around this since AKS/EKS/GKE don't expose the ability to edit api server parameters to users.

How does the API server verify the user's token?
Post reply on HN