> or that we have to fill passwords ... And using our Vault is optional.
So, "optional" unless there's a legacy password flow? I'm not trying to be a troll, just understand the line between the value you offer over 1P versus the passwordless claim
> Right now we are planning to release RDP support for Windows servers, and then we were planning to focus on adding support for databases. That is why your feedback is critical as we can reassess the priorities regarding Kubernetes.
Sounds good, but what is the plan for databases and then kubernetes? I know how Hashicorp Vault solves the database problem, and suspect you're going to take the same approach, but any "this is how we think about the world" would be helpful. Same for kubernetes, which thankfully already has strong support for externalized authn
the plan is to support remote access (eliminating VPN) to cloud-hosted database (in AWS, GCP) and also self-hosted database in the on-premise infrastructure. we be be leveraging access management service (eg AWS IAM) for passwordless access to cloud-hosted and will be leveraging cert-based authentication for self-hosted database.
For kubernetes cluster, we will be delivering a kubernetes service that will facilitate to access the cluster remotely from the kubectl.
So, "optional" unless there's a legacy password flow? I'm not trying to be a troll, just understand the line between the value you offer over 1P versus the passwordless claim
> Right now we are planning to release RDP support for Windows servers, and then we were planning to focus on adding support for databases. That is why your feedback is critical as we can reassess the priorities regarding Kubernetes.
Sounds good, but what is the plan for databases and then kubernetes? I know how Hashicorp Vault solves the database problem, and suspect you're going to take the same approach, but any "this is how we think about the world" would be helpful. Same for kubernetes, which thankfully already has strong support for externalized authn