AverageMarcus
/
blog
1
0
Fork 0
Code Issues Pull Requests Releases Activity

Fixed typo issue 

Signed-off-by: Marcus Noble <github@marcusnoble.co.uk>
This commit is contained in:
Marcus Noble 2022-05-29 17:10:29 +01:00
parent 6307509542
commit 0e97c82aa1
Signed by: AverageMarcus
GPG Key ID: B8F2DB8A7AEBAF78
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/posts/2022-01-20-restricting-cluster-admin.md
View File

@ -1,5 +1,5 @@
---
la///yout: post.html
layout: post.html
title: "Restricting cluster-admin Permissions"
date: 2022-01-20
tags: Kubernetes Kyverno RBAC
@ -32,11 +32,11 @@ rules:
There's very good reason for this, an admin generally needs to be able to setup and manage the cluster, including the ability to define and assign roles. But what if we need to _block_ an action performed by cluster admins? We can't do it with RBAC, it only allows for **adding** of permissions, not taking them away.
Well, recently at [Giant Swarm](https://giantswarm.io/) we had an [issue in one of our CLIs](https://github.com/giantswarm/kubectl-gs/pull/632) used by cluster admins that incorrectly deleted more resources than intended. This was causing issues authenticating with the cluster and we needed to get a fix in place _fast_. The problem was we had no control over when people would update their CLI even once we'd released the fix.
Well, recently at [Giant Swarm](https://giantswarm.io/) we had an [issue in one of our CLIs](https://github.com/giantswarm/kubectl-gs/pull/632) used by cluster admins that incorrectly deleted more resources than intended. This was causing issues authenticating with the cluster and we needed to get a fix in place _fast_. The problem was we had no control over when people would update their CLI even once we'd released the fix.
We couldn't hot-fix this by updating RBAC rules as we couldn't subtract the specific permission, but what we could do was leverage an [**admission controller**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) to block the request to the API.
At Giant Swarm we're pretty big users of [Kyverno](https://kyverno.io/) (which deploys an admission controller) and use it for a lot of validation and defaulting of resources in all our clusters. Not only can Kyverno validate and block based on a resource's values but it can also validate the _operation_ being performed, and by who.
At Giant Swarm we're pretty big users of [Kyverno](https://kyverno.io/) (which deploys an admission controller) and use it for a lot of validation and defaulting of resources in all our clusters. Not only can Kyverno validate and block based on a resource's values but it can also validate the _operation_ being performed, and by who.
With this functionality available we were able to deploy a cluster policy that would block cluster-admin (and anyone else) from performing the specific delete all action that was causing us issues.
@ -121,4 +121,4 @@ While we needed this to work around a bug in our client there are other situatio
* A policy that prevents fetching the details of secrets in a specific namespace while still allowing in every other namespace (including those that may not yet exist).
* A policy that blocks deletes, updates or patches from everyone except a specific user that can be used to prevent others "cleaning up" resources that you may be trying to debug.
So, if you haven't already, I recommend taking a look at [Kyverno](https://kyverno.io) and especially taking a look at the [example Policies](https://kyverno.io/policies/) that they have for an idea of what can be done.
So, if you haven't already, I recommend taking a look at [Kyverno](https://kyverno.io) and especially taking a look at the [example Policies](https://kyverno.io/policies/) that they have for an idea of what can be done.