Live data from Hacker News

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

github.com

41–50 of 59 posts

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

#41
post #39

Earlier quoted context omitted.

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?

Tokens are verified by intercepting API server requests in-cluster against a central root of trust. This is similar to how OpenID tokens from identity providers such as Okta or Active Directory are verified by destination web applications. This works no matter where clusters are hosted (including GKE/AKS/EKS or self-hosted clusters).

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

#44
post #41

Earlier quoted context omitted.

How does the API server verify the user's token?

Tokens are verified by intercepting API server requests in-cluster against a central root of trust. This is similar to how OpenID tokens from identity providers such as Okta or Active Directory are verified by destination web applications. This works no matter where clusters are hosted (including GKE/AKS/EKS or self-hosted clusters).

How do you avoid configuring the API server to support OIDC?

https://kubernetes.io/docs/reference/access-authn-authz/auth...

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

#45
post #41

Earlier quoted context omitted.

Tokens are verified by intercepting API server requests in-cluster against a central root of trust. This is similar to how OpenID tokens from identity providers such as Okta or Active Directory are verified by destination web applications. This works no matter where clusters are hosted (including GKE/AKS/EKS or self-hosted clusters).

How do you avoid configuring the API server to support OIDC? https://kubernetes.io/docs/reference/access-authn-authz/auth...

Seems like you intercept the request and use an admin service account token then impersonate?

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

#46

Earlier quoted context omitted.

How do you avoid configuring the API server to support OIDC? https://kubernetes.io/docs/reference/access-authn-authz/auth...

Seems like you intercept the request and use an admin service account token then impersonate?

Great question! Most managed Kubernetes services don't support OIDC (and for EKS, which does support custom OIDC providers, it requires restarting the entire control plane to edit the configuration).

Infra runs a lightweight process in-cluster that intercepts requests and verifies them - and yes, this process intercepts requests and then impersonates the correct users and groups.

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

#47

Why should someone use this instead of Vault, Teleport, or other PAM tools? Does it work with managed Kubernetes offerings like AKS/EKS/GKE?

Or dex (https://dexidp.io/) which seems to connect existing providers to Kubernetes (eg GitHub, LDAP)?

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

#48
Congratulations on the launch! Any and all competition in this space is welcome. We've been hoping that something open-source would take off since the pricing for Teleport/StrongDM is a bit out of our league.

With that in mind, can you comment on your strategy for exposing arbitrary infrastructure (i.e. non-kubernetes-native services)? We've been watching Hashicorp Boundary for some time and it seems like they have the right architectural approach.. but the DX is not quite there and the pace of development is slow. It seems like Infra's approach is similar (install an agent on the target infrastructure which communicates with a central API), but it's unclear if this can be used across clusters, vpcs, cloud providers or to connect to non-kubernetes infrastructure.

A few other questions to distinguish it from Boundary:

1. What can infra do to get an organization closer to meeting SOC2 compliance?

2. Is there a plan for a desktop UI?

3. What sort of timeline are we looking at for the custom IdP integration (e.g. Azure OIDC)

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

#49
post #47

Why should someone use this instead of Vault, Teleport, or other PAM tools? Does it work with managed Kubernetes offerings like AKS/EKS/GKE?

Or dex ( https://dexidp.io/ ) which seems to connect existing providers to Kubernetes (eg GitHub, LDAP)?

Great question! We looked heavily into Dex before creating Infra, and even spoke with their maintainers.

Dex is a federated OIDC provider. Most managed Kubernetes services (e.g. Azure AKS) don't support using custom OIDC providers for authentication and therefore can't easily be wired up to use Dex. Infra is designed to work with any Kubernetes distribution regardless of where it's hosted.

Even with self-hosted clusters that do support Dex, Dex doesn't manage authorization mappings (i.e. Kubernetes RBAC) for users and groups. Teams still need to manually create & remove RBAC roles for users and groups as they are added and removed from identity providers such as Okta. Infra can be configured to map roles for users and groups to Kubernetes clusters, and we're working to support dynamic provisioning protocols such as SCIM to make sure users are automatically revoked as they are removed from identity providers.

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

#50

Congratulations on the launch! Any and all competition in this space is welcome. We've been hoping that something open-source would take off since the pricing for Teleport/StrongDM is a bit out of our league. With that in mind, can you comment on your strategy for exposing arbitrary infrastructure (i.e. non-kubernetes-native services)? We've been watching Hashicorp Boundary for some time and it seems like they have t…

Thanks for the note — would love to hear what infrastructure outside of Kubernetes you’d like to connect to, so I can target the answer more specifically.

For expanding to infrastructure outside of Kubernetes, we will ultimately generating short-lived credentials from and distributing them to either humans or machine users. This can be done through different means, and we’ll select the best method for that infrastructure.

1. With where we want to take Infra, we want to enable teams to build an access system using the principles of least privilege so statically users can have a minimal permission (or no permission), and when access is needed, dynamically provision that access (automatic or manual approval depending on configuration). Infra will always be able to show who has access to what at any given time to satisfy audits.

Infra is currently self-hosted, and we will definitely be taking it through compliance audits & penetration tests (including SOC 2) as we mature the project.

2. Yes, we love desktop apps - starting from the early versions of Kite we've built, Kitematic, Docker desktop, and Infra app. We believe good software just works in the background without affecting users' flow.

3. We’ve already tried using both Google workspaces / Azure active directory via OIDC. It should work. We’re just not pitching it because we have not done extensive testing with it yet. I should note, Infra is OIDC-compliant, so it should work with any custom identity providers that support OIDC. (I will asterisk it because one OIDC-compliant provider may differ from another, even from a major vendor)

Post reply on HN