Kubernetes offers an amazing platform for application deployment and management.  As you’re building out your deployment, how will you secure it?  How will you control access to for developers and operators?  Kerbernetes offers support for OpenID Connect and Role Based Access Controls (RBAC) but how will you use these solutions to provide the security you need to meet your compliance requirements?

When securing access to Kubernetes you should consider:

  1. Kubernetes has no mechanism to trigger a login, so you’ll need something to collect credentials, generate an id_token and update your kubectl’s configuration
  2. Kubernetes doesn’t store users or group memberships requiring that you store them somewhere
  3. Whoever controls your enterprise’s Active Directory will not generally let individual applications store groups inside of the enterprise AD
  4. The Kubernetes’ dashboard doesn’t support authentication

If you can’t store groups in AD, where can you store them?   If you’re providing self service to your customers do you want to have to create those groups and users manually?  Do you want to have to write your own system for managing access?  How will you track requests?  How will you track approvals?  Escalations?  Re-certification of access?

Tremolo Security’s open source identity management solutions provide both an application that provides user self service and APIs that can be hooked into your existing CI/CD pipeline.

 Both Unison and OpenUnison support OpenID Connect and can either directly authenticate the user or proxy the authentication to another identity provider via OpenID Connect or SAML2.  This opens up a wide range of options for Kubernetes access authentication such as:

  1. Authenticate via SAML2 to your enterprise ADFS or other identity service
  2. After authenticating, add multi-factor authentication for privileged access
  3. Provide an authentication layer for the dashboard
  4. Refresh tokens while your session is active directly from kubectl

Once a user is authenticated, they need to be authorized.  Unison and OpenUnison will both let you store your authorization data separately from your authentication data.  This means you could store data in a relational database, a NoSQL database like Mongo or any other store that is convenient for your team.  Once you have decided where to store groups Unison and OpenUnison provide:

  1. Self Service Access Requests – Developers and Operators can login to a central application to request access to the projects they need without creating a manual email trail
  2. Dynamic Workflows – Available requests are driven dynamically by your OpenShift configuration and annotations on your project so there’s no manual intervention when new projects are created.
  3. RESTful API – Call our API to create access for bulk onboardings, new projects, etc
  4. Reporting – Use our integrating reporting tools or your favorite business intelligence system to determine who has access to what and why without tracking down emails to see why users had access

Finally, you can Unison and OpenUnison as a powerful identity service for applications running on Kubernetes.  Providing the best of both centralized identity management with decentralized deployments Unison and OpenUnison can provide compliance and security services for applications that are independent of their development process making it easier to develop secure applications on Kubernetes.

If you’re interested in the details of how Kubernetes authentication and authorization work we have put together a detailed wiki page that walks through the concepts and step-by-step configuration options.

Marc BoorshteinKubernetes