How do I install the Cis Gke V170 4.1.6 skill?

Run npx skillmds@latest add cyberstrikeus/cis-gke-v170-4-1-6 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Cis Gke V170 4.1.6 skill do?

Avoid use of system:masters group (Automated) It is listed under DevOps & Infra on SkillMD.

Is Cis Gke V170 4.1.6 safe to use?

SkillMD's automated safety review verdict for this skill is PASS. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Cis Gke V170 4.1.6?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Cis Gke V170 4.1.6 free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Cis Gke V170 4.1.6?

cyberstrikeus (@cyberstrikeus) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Cis Gke V170 4.1.6 by cyberstrikeus

Name: Cis Gke V170 4.1.6
Author: cyberstrikeus

File contents

4.1.6 Avoid use of system:masters group (Automated)

Profile Applicability

Level 1

Description

The special group system:masters should not be used to grant permissions to any user or service account, except where strictly necessary (e.g. bootstrapping access prior to RBAC being fully available).

Rationale

The system:masters group has unrestricted access to the Kubernetes API hard-coded into the API server source code. An authenticated user who is a member of this group cannot have their access reduced, even if all bindings and cluster role bindings which mention it, are removed.

When combined with client certificate authentication, use of this group can allow for irrevocable cluster-admin level credentials to exist for a cluster.

GKE includes the CertificateSubjectRestriction admission controller which rejects requests for the system:masters group.

CertificateSubjectRestriction "This admission controller observes creation of CertificateSigningRequest resources that have a spec.signerName of kubernetes.io/kube-apiserver-client. It rejects any request that specifies a 'group' (or 'organization attribute') of system:masters." https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction

Impact

Once the RBAC system is operational in a cluster system:masters should not be specifically required, as ordinary bindings from principals to the cluster-admin cluster role can be made where unrestricted access is required.

Audit

Review a list of all credentials which have access to the cluster and ensure that the group system:masters is not used.

Remediation

Remove the system:masters group from all users in the cluster.

Default Value

By default some clusters will create a "break glass" client certificate which is a member of this group. Access to this client certificate should be carefully controlled and it should not be used for general cluster operations.

References

https://github.com/kubernetes/kubernetes/blob/master/pkg/registry/rbac/escalation_check.go#L38

CIS Controls

Controls Version	Control	IG 1	IG 2	IG 3
v8	5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts	*	*	*
v7	4 Controlled Use of Administrative Privileges

---name: cis-gke-v170-4-1-6description: Avoid use of system:masters group (Automated)---# 4.1.6 Avoid use of system:masters group (Automated)## Profile Applicability- Level 1## DescriptionThe special group `system:masters` should not be used to grant permissions to any user or service account, except where strictly necessary (e.g. bootstrapping access prior to RBAC being fully available).## RationaleThe `system:masters` group has unrestricted access to the Kubernetes API hard-coded into the API server source code. An authenticated user who is a member of this group cannot have their access reduced, even if all bindings and cluster role bindings which mention it, are removed.When combined with client certificate authentication, use of this group can allow for irrevocable cluster-admin level credentials to exist for a cluster.GKE includes the `CertificateSubjectRestriction` admission controller which rejects requests for the `system:masters` group.`CertificateSubjectRestriction` "This admission controller observes creation of `CertificateSigningRequest` resources that have a spec.signerName of kubernetes.io/kube-apiserver-client. It rejects any request that specifies a 'group' (or 'organization attribute') of system:masters." https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#certificatesubjectrestriction## ImpactOnce the RBAC system is operational in a cluster `system:masters` should not be specifically required, as ordinary bindings from principals to the `cluster-admin` cluster role can be made where unrestricted access is required.## AuditReview a list of all credentials which have access to the cluster and ensure that the group `system:masters` is not used.## RemediationRemove the `system:masters` group from all users in the cluster.## Default ValueBy default some clusters will create a "break glass" client certificate which is a member of this group. Access to this client certificate should be carefully controlled and it should not be used for general cluster operations.## References1. https://github.com/kubernetes/kubernetes/blob/master/pkg/registry/rbac/escalation_check.go#L38## CIS Controls| Controls Version | Control | IG 1 | IG 2 | IG 3 || ---------------- | ------------------------------------------------------------------------- | ---- | ---- | ---- || v8 | 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts | \* | \* | \* || v7 | 4 Controlled Use of Administrative Privileges | | | |

Frequently asked questions

Cis Gke V170 4.1.6