Home Explore Blog CI



kubernetes

2nd chunk of `content/en/blog/_posts/2017-10-00-Using-Rbac-Generally-Available-18.md`
85c53b626ef24bb3f9745ff76b0de06baff55dc0dd53bd520000000100000b83
Because we used a RoleBinding, these powers only apply within the RoleBinding’s namespace. In our case, a user in the “infra” group can view resources in the “dev” namespace but not in “prod”:  


 ```  

$ kubectl get deployments --as=dave --as-group=infra --namespace dev

No resources found.

$ kubectl get deployments --as=dave --as-group=infra --namespace prod

Error from server (Forbidden): deployments.extensions is forbidden: User "dave" cannot list deployments.extensions in the namespace "prod".

  ```

## Creating custom roles
When the default ClusterRoles aren’t enough, it’s possible to create new roles that define a custom set of permissions. Since ClusterRoles are just regular API resources, they can be expressed as YAML or JSON manifests and applied using kubectl.  

Each ClusterRole holds a list of permissions specifying “rules.” Rules are purely additive and allow specific HTTP verb to be performed on a set of resource. For example, the following ClusterRole holds the permissions to perform any action on "deployments”, “configmaps,” or “secrets”, and to view any “pod”:  


 ```  

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1

metadata:

  name: deployer

rules:

- apiGroups: ["apps"]

  resources: ["deployments"]

  verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]



- apiGroups: [""] # "" indicates the core API group

  resources: ["configmaps", "secrets"]

  verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]



- apiGroups: [""] # "" indicates the core API group

  resources: ["pods"]

  verbs: ["get", "list", "watch"]

  ```


Verbs correspond to the HTTP verb of the request, while the resource and API groups refer to the resource being referenced. Consider the following Ingress resource:  


 ```  

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: test-ingress

spec:

  backend:

    serviceName: testsvc

    servicePort: 80

  ```


To POST the resource, the user would need the following permissions:  


 ```  

rules:

- apiGroups: ["extensions"] # "apiVersion" without version

  resources: ["ingresses"]  # Plural of "kind"

  verbs: ["create"]         # "POST" maps to "create"

  ```



## Roles for applications
When deploying containers that require access to the Kubernetes API, it’s good practice to ship an RBAC Role with your application manifests. Besides ensuring your app works on RBAC enabled clusters, this helps users audit what actions your app will perform on the cluster and consider their security implications.  

A namespaced Role is usually more appropriate for an application, since apps are traditionally run inside a single namespace and the namespace's resources should be tied to the lifecycle of the app. However, Roles cannot grant access to non-namespaced resources (such as nodes) or across namespaces, so some apps may still require ClusterRoles.  

Title: Creating Custom Roles and Roles for Applications
Summary
The document explains how to create custom roles in Kubernetes when the default ClusterRoles are insufficient. Custom roles are defined as YAML or JSON manifests and applied using kubectl, specifying a list of permissions with 'rules' that define HTTP verbs on resources. It also emphasizes the importance of including RBAC Roles with application manifests for applications that require access to the Kubernetes API, promoting security and auditability. Namespaced Roles are generally preferred for applications, but ClusterRoles may be necessary for accessing non-namespaced resources.