3 ms·

How does this compare to the OIDC integration with Kubernetes which is supported natively out of the box? You can hook up an enterprise IdP like AD FS with tha

How does this compare to the OIDC integration with Kubernetes which is supported natively out of the box? You can hook up an enterprise IdP like AD FS with that, without any additional software.

aberoham 8y ago
The biggest difference is that Teleport is a full MITM for all apiserver traffic, leveraging the cluster-local certificate authority for short-lived creds (similar to how K8s internal bits such as the kubelet speaks TLS to the apiserver). Notably this also works with completely air-gapped clusters or end-users, or clusters where you want access to apiserver to be via egress (hidden bastion) only. K8s authentication methods that go inline with the apiserver, such as oidc or dex, achieve the same goals but are a bit of a different design flavor and arguably less clean from a threat or failure model perspective.
- madjam002 8y ago
  How is OIDC less clean from a threat/failure model perspective? If your organisation has implemented an OIDC IdP, you can have the API server behind a Bastion like you suggest, and accessible through an authenticating reverse proxy (Beyondcorp style) WAF. You can even have token bound access/ID tokens which are backed by hardware TPMs if you're REALLY paranoid (upcoming spec). Plus because it's an open standard which K8s heavily embraces, you get rich group/user claims mapping in K8s allowing for logging and auditing.
old-gregg 8y ago
The obvious benefit is that synchronizes Kubernetes auth with SSH access, i.e. you don't have to authenticate twice if your organization uses SSH-based tools and k8s-based tooling, moreover it extends the same RBAC rules to both SSH and k8s, i.e. "developers must not touch production data" will be enforced for both "ssh production-host" and "kubectl exec production-pod". The second, perhaps less obvious, benefit is Teleport's built-in audit as shown in the video, i.e. all your interactions with all Kubernetes clusters are logged in one centralized place for audit purposes (and, in the case of the interactive sessions) can be replayed in a Youtube-like player. But yes, if you don't need the audit, and you don't use SSH, and if you only have one k8s cluster, this may be an overkill.
raesene9 8y ago
OIDC generally requires additionally add-ins (e.g. Dex, or keycloak) to operate with things like AD.
- madjam002 8y ago
  Not since Server 2016, it works out of the box with AD FS which is a Windows Server Feature.

How does this compare to the OIDC integration with Kubernetes which is supported natively out of the box? You can hook up an enterprise IdP like AD FS with that, without any additional software.

aberoham 8y ago

The biggest difference is that Teleport is a full MITM for all apiserver traffic, leveraging the cluster-local certificate authority for short-lived creds (similar to how K8s internal bits such as the kubelet speaks TLS to the apiserver). Notably this also works with completely air-gapped clusters or end-users, or clusters where you want access to apiserver to be via egress (hidden bastion) only. K8s authentication methods that go inline with the apiserver, such as oidc or dex, achieve the same goals but are a bit of a different design flavor and arguably less clean from a threat or failure model perspective.

madjam002 8y ago
How is OIDC less clean from a threat/failure model perspective? If your organisation has implemented an OIDC IdP, you can have the API server behind a Bastion like you suggest, and accessible through an authenticating reverse proxy (Beyondcorp style) WAF. You can even have token bound access/ID tokens which are backed by hardware TPMs if you're REALLY paranoid (upcoming spec). Plus because it's an open standard which K8s heavily embraces, you get rich group/user claims mapping in K8s allowing for logging and auditing.

old-gregg 8y ago

The obvious benefit is that synchronizes Kubernetes auth with SSH access, i.e. you don't have to authenticate twice if your organization uses SSH-based tools and k8s-based tooling, moreover it extends the same RBAC rules to both SSH and k8s, i.e. "developers must not touch production data" will be enforced for both "ssh production-host" and "kubectl exec production-pod". The second, perhaps less obvious, benefit is Teleport's built-in audit as shown in the video, i.e. all your interactions with all Kubernetes clusters are logged in one centralized place for audit purposes (and, in the case of the interactive sessions) can be replayed in a Youtube-like player. But yes, if you don't need the audit, and you don't use SSH, and if you only have one k8s cluster, this may be an overkill.

raesene9 8y ago

OIDC generally requires additionally add-ins (e.g. Dex, or keycloak) to operate with things like AD.

madjam002 8y ago
Not since Server 2016, it works out of the box with AD FS which is a Windows Server Feature.