alexk

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.

alexk

3 年前議論

Thank you! I made a copy-paste error, fixed.

alexk

3 年前議論

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.

What to expect once you apply: * 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.

https://jobs.lever.co/teleport/7c7f25dd-21c7-45c9-a107-98d8a...

alexk

3 年前議論

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.

alexk

3 年前議論

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 :)

alexk

3 年前議論

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.

alexk

3 年前議論

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

alexk

3 年前議論

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.

alexk

3 年前議論

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.

What to expect once you apply:

  * 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.

https://jobs.lever.co/teleport/7c7f25dd-21c7-45c9-a107-98d8a...

alexk

4 年前議論

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.

alexk

4 年前議論

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.

alexk

4 年前議論

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.

alexk

4 年前議論

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.

alexk

4 年前議論

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.

alexk

4 年前議論

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.

alexk

4 年前議論

gk1 thanks, this is a valid point!

Teleport solves many quite important problems four our enterprise customers' infrastructure. Our users use Teleport to replace secrets and static keys with short lived certificates, manage certificate authorities, add audit and compliance controls for access to critical data, consolidate access for SSH, Kubernetes, Databases and Desktops.

alexk

4 年前議論

That's a fair question. The team votes on specific aspects of implementation that can not be verified by running a program, for example:

* Error handling and code structure - whether the code processes errors well and has a clear and modular structure or crashes on invalid inputs, or the code works, but is all in one function.

* Communication - whether all PR comments have been acknowledged during the code review process and fixed.

Others, like whether the code uses good setup of HTTPS and has authn are more clear.

However, you have a good point. I will chat to the team and see if we can reduce the amount of things that are subject to personal interpretation and see if we can replace them with auto checks going forward.

alexk

4 年前議論

Sasha, CTO @ Teleport here.

I agree, our enterprise product is quite expensive. Let me explain why:

* We are going through several security audits by third party agencies several times per year. We are trying to hire the best security agencies to audit our code and it is quite expensive.

* We are recruiting globally and try to place our comp at 90th+ percentile of the compensation as listed in opencomp.com and other sources we have access to.

* Our sales process also takes time, and the sales team employs sales engineers, sales and customer success specialists to assist with deployments of such a critical piece of the infrastructure.

* For all our employees we have wellness benefits for home office improvement, personal development, healthcare packages.

All of these factors above add up and we charge a lot for building a quality security product supported 24/7 across the globe.

However, this might not work for everyone, and we have a completely free and open source version that people can use without ever talking to our sales team:

https://github.com/gravitational/teleport

alexk

4 年前議論

Hey, I'm Sasha, CTO @ Teleport. I have designed our interview process and have described it here:

https://goteleport.com/blog/coding-challenge/

We are also trying to be as transparent as possible with our challenges being open source:

https://github.com/gravitational/careers/tree/main/challenge...

and requirements being published here:

https://github.com/gravitational/careers/blob/main/levels.pd...

I am sorry to hear that you had bad experience. Our interview process is a trade-off and has one big downside - it may take more time and efforts compared to classic interviews. It could also feel disappointing if the team does not vote in favor of the candidate's application.

However, if there was something else wrong with your experience and you are willing to share, please send me an email to [email protected].

alexk

5 年前議論

Teleport (YC S15) | Backend, Fullstack, Frontend Engineer | US, Europe, Canada, Brazil, Australia, Remote OK | https://goteleport.com

Do you enjoy building security and deployment tools for other engineers? Join us to hack on https://github.com/gravitational/teleport anywhere in the U.S, Canada, Europe, Brazil, Australia. Most of our code is Go, we have very little technical debt, our codebase is clean and small.

If you are backend and fullstack engineer, we expect you to be comfortable with the following:

  * Go or Rust for backend and Typescript for frontend engineers
  * Linux, networking.
  * Scalability or security experience for systems software is welcome.

We’re looking for senior and junior engineers to join the Teleport team. Teleport is a company started by engineers to build products for engineers. We are a stable and growing company.

We offer:

  * Competitive salary and equity.
  * 401k with company match.
  * Excellent health insurance.
  * Work anywhere in the U.S, Canada, Europe, Australia, Brazil

Apply: https://jobs.lever.co/teleport

What to expect once you apply:

  * We will send you a 20-30 minute programming quiz
  * You will join 30 minute intro call and we will walk you through the compensation,
    interview process and requirements.
  * You join a slack channel and submit a coding challenge in Golang, Rust or Typescript depending on the position, using Github.

投稿

Preventing CSRF Attacks

XSS Attack Examples and Mitigations

SSH Certificates Security

San Antonio’s Scaleworks Acquires Keen IO

Migrating to Kubernetes

Introducing the Kubernetes Kubelet in CoreOS Linux

Demonstrating the Datacenter Operating System – Mesosphere

Show HN: Vulcand – Proxy for microservices and API

Creating containers – Part 1

Godep for End User Go Projects

Vulcand news: Metrics, anomaly detection and improved tools

Ghost and Mailgun integration made easier

Load balancing with Vulcan and Etcd

Charming Python: SimPy simplifies complex models

Hacking dance

Towards a Standard Parser Generator

Python futures - execute computations asynchronously

Regular expression speed comparison

Lava Flow

Turing Machine

コメント