BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    Use Cases and Industries
    See All Products
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Using Role-based Access Control (RBAC) to Tighten Kubernetes Security

February 10, 2020

  • Blog
  • Archive

In my most recent Kubernetes attack and defense webinar, I demonstrate a Kubernetes attack through a Scott Pilgrim-themed scenario. If you haven’t seen the Scott Pilgrim movie, definitely check it out!

The attacks in my webinar demonstrate defeating the “evil ex” bad guys of the movie as you escalate privilege through a Linux-based Kubernetes cluster. In one step, we gain a password through a monkey-in-the-middle (MitM) attack, where we intercept a communication between two containers in the cluster. It’s much easier than it sounds!

There are a number of defenses we discuss in the webinar. The most widely applicable is Kubernetes’ primary authorization rules language, called role-based access control (RBAC). RBAC is pretty easy to learn.

You use RBAC to help implement least privilege by defining what accounts (user accounts or service accounts) can perform what actions to what resources. You’d expect this would mean that we create a number of rule objects, like so:

User Jay may list pods

User Mary may list pods

User Alice may get, list, watch, create, update, patch, delete pods

To ease handling a large number of accounts, RBAC uses a sort of intermediate item called a binding. You create “roles,” which have a set of capabilities, then give each user one or more roles via a “rolebinding.” That last example would use a pair of custom roles:

Role pod-lister may list pods

Role pod-rw may get, list, watch, create, update, patch, delete pods

Then you create rolebindings, giving Jay and Mary the pod-lister role, while you give Alice the pod-rw role, like so:

User Jay has role pod-lister

User Mary has role pod-lister

User Alice has role pod-rw

Once this makes sense to you, you only need to grasp one additional concept. Kubernetes ties all of these to “namespaces,” an organizational unit that is customarily used to separate development teams or projects from one another in a cluster. So, you create these roles (sets of actions) and rolebindings (grants of roles to users) in one namespace at a time. For a rare set of cases where you need the capabilities to affect the entire cluster, not just one namespace, you can create “cluster roles” and “cluster rolebindings.”

But wait, you say, isn’t this all supposed to be expressed in YAML? (Footnote: YAML stands for “YAML Ain’t Markup Language). Yes, it is, but it’s quite a bit easier to understand the YAML when you know what it’s supposed to be doing.

Here’s the YAML version of “Role pod-lister may list pods”:

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: pod-lister

rules:

- apiGroups: [""]

verbs: ["list"]

resources: ["pods"]

Here’s the YAML version of “User Jay has role pod-lister”

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1

metadata:

name: user-jay-has-role-pod-lister

subjects:

- kind: User

name: jay

apiGroup: ""

roleRef:

kind: Role

name: pod-lister

apiGroup: ""

There’s a lot more you can learn about how to effectively and efficiently leverage RBAC, but what you’ve learned in this blog post is enough for you to defend the Kubernetes cluster we attack in my on-demand webinar. Follow along here: Attacking and Defending Kubernetes Scott Pilgrim–Style.

Photograph of Jay Beale

Jay Beale, co-founder, COO and CTO, InGuardians

Jay Beale has created several defensive security tools, including Bastille Linux/UNIX and the CIS Linux Scoring Tool, both of which were used widely throughout industry and government. He has served as an invited speaker at many industry and government conferences, a columnist for Information Security Magazine, SecurityPortal and SecurityFocus, and a contributor to nine books, including those in his Open Source Security Series and the “Stealing the Network” series. He has led training classes on Linux Hardening and other topics at Black Hat, CanSecWest, RSA, and IDG conferences, as well as in private corporate training. Jay is a co-founder, Chief Operating Officer and CTO of the information security consulting company InGuardians.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Whitepapers

Mapping BeyondTrust Capabilities to NIST SP 800-207

Whitepapers

Mapping BeyondTrust Solutions to the Identity, Credential, and Access Management (ICAM) Architecture

Whitepapers

Four Key Ways Governments Can Prepare for the Growing Ransomware Threat

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.