alexk
Joined 18 years ago
Karma
1,782
Submissions
497
Member since
Mar 20
Recent submissions
Comment · 1 year ago
For folks interested in 101 on linear algebra - I highly recommend book "Linear Algebra: Theory, Intuition, Code" by Mike X Cohen.
After trying a couple of courses and books, I liked it the most because it gives a pretty deep overview of the concepts, alongside the numpy and matlab code, which I found refreshing.
It's has good amount of proofs and has sections designed to build your intuition, which I really appreciated.
Comment · 3 years ago
Thank you! I made a copy-paste error, fixed.
Comment · 3 years ago
Teleport (YC S15) | Senior Technical Support Engineer | US, Europe, Canada, Remote OK | https://goteleport.com
We are looking for Senior Tech Support Engineers who can script, love systems troubleshooting and helping customers.
Join Us:
https://jobs.lever.co/teleport/7c7f25dd-21c7-45c9-a107-98d8a...
Most of our code is Go, we have very little technical debt, our codebase is clean and small.
We expect you to be comfortable with the following:
* Scripting in Python, Go or Bash
* Deep understanding of Linux and networking administration
* Understanding of modern infra stacks - Kubernetes, Terraform, Ansible
* Scalability or security experience for systems software is welcome.https://jobs.lever.co/teleport/7c7f25dd-21c7-45c9-a107-98d8a...
Comment · 3 years ago
They key difference is with mTLS approach you'd have to steal the private key of the client certificate if you want to impersonate the client. In most secure deployments of mTLS and short lived certs, private key never escapes the TPM, Secure enclave or Yubikey, so it's extremely hard to mount an attack and impersonate a service.
With JWT (assuming it's not bound) you can steal JWT token and re-use it until it expires.
Comment · 3 years ago
No problem! Keep it up with out of the box integrations, focus on U.X. and developer experience and I think you will be on track to become as big or bigger than Hashicorp :)
Comment · 3 years ago
I don't think those are mutually exclusive options :) Most developers, especially with lots of legacy apps are better off using a secrets manager. But there is no reason to not push the boundaries of security for new software and onboard passwordless and secretless options.
P.S.
I tried Infisical a couple of months ago. I think if I was Hashicorp Vault team's PM, I'd be worried. Your team has done such a great job at U.X. I was astonished to see an early startup with such a great integration catalog. I think you aced it - modern developers are desperate for out of the box integrations with 100+ services they have to use every day.
Comment · 3 years ago
Short version is that with mTLS and short-lived certificates you don't have to worry about anyone stealing and re-using your JWT tokens and revoking tokens.
LVH from Latacora explains it way better than I could in "A child's garden of inter-service authentication" [1]
However, here is my view:
If your token is not bound to the connection, someone can steal and reuse it, just like any other token. It is possible to use OAuth token binding [2], but at this level of complexity, mTLS + short lived certs deliver the same security and are easier to deploy.
It's easy to mess up JWT signatures, although, to be fair, it's not like X.509 certificates format is any better, however it's been more tested over years of use.
[1] https://latacora.micro.blog/2018/06/12/a-childs-garden.html [2] https://connect2id.com/learn/token-binding
Comment · 3 years ago
You can't leak API keys if there are no API keys to leak! The article recommends OIDC for apps, which is a step up, especially if you rotate the bearer token, however there is another option - use short-lived certs.
Our project Machine ID is replacing API keys with short-lived certificates:
https://goteleport.com/docs/machine-id/introduction/
Another great option is SPIFFEE https://spiffe.io/
The adoption is slower than we wanted, because it's not trivial to replace API keys, but we see more and more companies using mTLS + short lived certs as alternative to shared secrets.
Comment · 3 years ago
Teleport (YC S15) | Senior Technical Support Engineer | US, Europe, Canada, Remote OK | https://goteleport.com
We are looking for Senior Tech Support Engineers who can script, love systems troubleshooting and helping customers.
Join Us:
https://jobs.lever.co/teleport/7c7f25dd-21c7-45c9-a107-98d8a...
Most of our code is Go, we have very little technical debt, our codebase is clean and small.
We expect you to be comfortable with the following:
* Scripting in Python, Go or Bash
* Deep understanding of Linux and networking administration
* Understanding of modern infra stacks - Kubernetes, Terraform, Ansible
* Scalability or security experience for systems software is welcome.
* We will send you a 30-50 minute SRE hacking/troubleshooting quiz
* You will join 30 minute intro call and we will walk you through the compensation, interview process and requirements.
* You will join a live troubleshooting session simulation and try to find all issues we planted in a cloud infrastructure.
Comment · 4 years ago
Sasha, CTO@ Teleport here. Thank you for the kind words! And congrats to the Tailscale team on launching SSH product.
Let me share a bit more about our auditing capabilities:
Teleport captures session PTY output and stores it in S3 or any S3 compatible storage for your records by default.
If you would like to get additional, more in-depth insight into the session, Teleport captures syscalls, file access calls and network calls done during SSH session by correlating it with sessions' cgroup using our BPF module:
https://goteleport.com/docs/server-access/guides/bpf-session...
Teleport provides a lot of other in-depth SSH integration for auditing and compliance, for example we support moderated sessions access control with a required session moderator, or per session-MFA.
Comment · 4 years ago
Sorry you feel that way!
We haven't counted, but my bet is that most smaller deployments just use the single proxy.
I also know that most larger deployments use multi-DC and multi-cluster design with independent CAs for availability and latency.
Comment · 4 years ago
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, you don't have to have a centralized proxy, you can just deploy Teleport proxy agent in each cluster and hide your K8s endpoint.
You also don't have to have a single Teleport proxy to do that.
Comment · 4 years ago
Teleport consists of a couple of components:
* Proxy is used to handle SSO, Web UI and intercept traffic for session capture. You can have one proxy per your organization, multiple proxies or, if you don't want to intercept traffic, no proxies at all.
* Auth server is used to issue certificates and send audit logs and session recordings to external systems.
* Nodes (end system agents) sometimes are helpful, but not required. For example, if you want to capture system calls in your SSH session, you can deploy node. Or you can use OpenSSH with Teleport if you wish.
Because Teleport is based on certificate authorities, the following deployments are possible:
* One, "centralized" HA pair of proxies intercepting all your traffic (K8s, databases, web, etc). This is actually helpful for many cases, as you have just one entry point in your system to protect, vs many.
* Multiple, "decentralized" proxies in multiple datacenters. This is helpful for large organizations with many datacenters all over the world.
* No proxies at all. You can issue certificates with or without Teleport and reach your target clusters directly, as long as they trust the CA. It's a bit harder for managed K8s, but easy to do with self-hosted K8s, SSH, Databases, etc that support mTLS cert auth. This is super helpful for integrations with larger echo system - any system that supports cert auth should work with Teleport out of the box.
* You can have one auth server HA pair managing a single certificate authority.
* You can have multiple, independent auth servers (teleport clusters) with certificate authorities and trust established between them.
* You can use your own CA tooling with Teleport.
The way we think about Teleport is that it's a combination of certificate authority management system, proxies (intercepting traffic and recording sessions) and nodes (for some services, like SSH providing advanced auditing capabilities with BPF).
You can combine those components, or replace them with whatever makes sense.
Comment · 4 years ago
Sasha, CTO@Teleport here. Congrats on the launch!
RE: Teleport design
Teleport does not require a centralized proxy, because it is based on certificate authorities. You can issue a certificate with or without Teleport proxy and access any cluster that trusts that certificate directly.
Because of this design you can have a completely decentralized system, with cold storage for your CA, HSM or any parallel system issuing certificates. There is also no need to revoke your credentials, because your certs are short-lived and bound to the device and cluster, so there is less opportunity for pivot attacks.
RE: GRPC
First version of Teleport also had HTTP/JSON REST API, but we have migrated to GRPC to support events streaming and have one type system across multiple languages and services boundaries.
Re: Managed clusters
Teleport supports all CNCF-compatible clusters, including AKS, EKS and GKE out of the box.
Comment · 4 years ago
That's a fair concern. We don't have extra steps to the interview process, our team votes only on the submitted code. However, We did not spend enough time thinking about automating as many of those steps as possible as we should have.
For some challenges we wrote a public linter and tester, so folks can self-test and iterate before they submit the code:
https://github.com/gravitational/fakeiot
I'll go back and revise these with the team, thanks for the hint.
Teleport allows engineers and security professionals to unify access for SSH servers, Kubernetes clusters, web applications, and databases across all environments.