{"id":1042,"date":"2017-08-23T21:25:43","date_gmt":"2017-08-24T02:25:43","guid":{"rendered":"https:\/\/www.softwareab.net\/wordpress\/?p=1042"},"modified":"2017-08-30T16:35:02","modified_gmt":"2017-08-30T21:35:02","slug":"kubernetes-dashboard-authentication-isolation","status":"publish","type":"post","link":"https:\/\/www.softwareab.net\/wordpress\/kubernetes-dashboard-authentication-isolation\/","title":{"rendered":"Kubernetes Dashboard, Authentication, Isolation"},"content":{"rendered":"

Hello All. Today we are going to look at Kubernetes Dashboard, Authentication, and Isolation.<\/p>\n

The Code<\/h2>\n

Let’s put the code up front; that way, if you don’t want to bother with the article you can start by poking around on your own. Example scripts and manifests are located at the kube-dex-dashboard GitHub repo<\/a>.<\/p>\n

Still there? Great! Let’s talk about the problem…<\/p>\n

The Problem<\/h2>\n

Per this thread on GitHub<\/a> we had a problem; we had installed kubeadm<\/a> and configured the Kubernetes Dashboard<\/a>. Moreover, we used CoreOS dex<\/a> to integrate our backing FreeIPA<\/a> domain for authentication.<\/p>\n

The logic flow to demonstrate the problem is very simple:<\/p>\n

    \n
  1. Use kubectl proxy<\/code> to access dashboard<\/li>\n
  2. In the dashboard, select an unpermitted namespace<\/li>\n
  3. Create a deployment – it would be denied to the user when running kubectl from the CLI. But this same deployment is permitted under the dashboard.<\/li>\n<\/ol>\n

    So that is what<\/em> – now for why<\/em>. The problem occurs because – out-of-the-box – Kubernetes Dashboard runs as a system-level process, normally with full cluster permissions. The issue arises when a user wants to authenticate and use the Dashboard – the user effectively runs as the same system identity that Dashboard uses.<\/p>\n

    Effectively we could not let our users take advantage of the Kubernetes dashboard due to privilege escalation. Bummer.<\/p>\n

    The Solution<\/h2>\n

    Our solution works around this problem by creating multiple Dashboards – one for each authorized user. It’s not pretty, it’s not particularly scalable, but it works.<\/p>\n

    Let’s Look at dex<\/strong>, AUTHN, and AUTHZ<\/h3>\n

    Before we jump into the specific multi-dashboard setup, let’s start by looking at authentication for our cluster. Kubernetes Authentication<\/a> is implemented by the Kubernetes API Server<\/a>; this makes sense because commands issued via kubectl (the Kubernetes CLI)<\/a> execute against the API Server. So it follows that to configure authentication within Kubernetes, you will have specific options in your \/etc\/kubernetes\/manifests\/kube-apiserver.yaml<\/code> manifest.<\/p>\n

    Kubernetes API Server Configuration and dex<\/code><\/h4>\n

    The following is how we configured the API server to delegate authentication and authorization to dex<\/code>:<\/p>\n

    \r\nspec:\r\n  containers:\r\n  - command:\r\n    - kube-apiserver\r\n    [...various cruft...]\r\n    - --authorization-mode=RBAC\r\n    - --oidc-issuer-url=https:\/\/kubeadm-clu2.hlsdev.local:32000\r\n    - --oidc-client-id=[our-secret]\r\n    - --oidc-ca-file=[issuing-CA-key]\r\n    - --oidc-username-claim=sub\r\n    - --oidc-groups-claim=groups\r\n<\/code><\/pre>\n
    Let’s quickly discuss the main settings (for gory details on setting up dex<\/code> as an RBAC authenticator, see Kubernetes RBAC Authentication setup<\/a>).<\/p>\n