Roles for Applications, Service Accounts, and Getting Involved

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. The following Role allows a Prometheus instance to monitor and discover services, endpoints, and pods in the “dev” namespace: ``` kind: Role metadata: name: prometheus-role namespace: dev rules: - apiGroups: [""] # "" refers to the core API group Resources: ["services", "endpoints", "pods"] verbs: ["get", "list", "watch"] ``` Containers running in a Kubernetes cluster receive service account credentials to talk to the Kubernetes API, and service accounts can be targeted by a RoleBinding. Pods normally run with the “default” service account, but it’s good practice to run each app with a unique service account so RoleBindings don’t unintentionally grant permissions to other apps. To run a pod with a custom service account, create a ServiceAccount resource in the same namespace and specify the `serviceAccountName` field of the manifest. ``` apiVersion: apps/v1beta2 # Abbreviated, not a full manifest kind: Deployment metadata: name: prometheus-deployment namespace: dev spec: replicas: 1 template: spec: containers: - name: prometheus image: prom/prometheus:v1.8.0 command: ["prometheus", "-config.file=/etc/prom/config.yml"] # Run this pod using the "prometheus-sa" service account. serviceAccountName: prometheus-sa --- apiVersion: v1 kind: ServiceAccount metadata: name: prometheus-sa namespace: dev ``` ## Get involved Development of RBAC is a community effort organized through the [Auth Special Interest Group](https://github.com/kubernetes/community/blob/master/sig-auth/README.md), one of the [many SIGs](https://github.com/kubernetes/community/blob/master/sig-list.md) responsible for maintaining Kubernetes. A great way to get involved in the Kubernetes community is to join a SIG that aligns with your interests, provide feedback, and help with the roadmap. ## About the author Eric Chiang is a software engineer and technical lead of Kubernetes development at [CoreOS](https://coreos.com/?utm_source=k8sblog&utm_medium=social&utm_campaign=organic), the creator of Tectonic, the enterprise-ready Kubernetes platform. Eric co-leads Kubernetes SIG Auth and maintains several open source projects and libraries on behalf of CoreOS.

This section discusses the use of RBAC Roles with application manifests for Kubernetes deployments. It highlights the importance of using namespaced Roles for applications confined to a single namespace, while acknowledging the need for ClusterRoles for broader access. It provides an example of a Role that allows a Prometheus instance to monitor services, endpoints, and pods. Furthermore, it covers the use of service accounts to manage container access to the Kubernetes API, advocating for unique service accounts per application. Finally, it encourages community involvement through the Auth Special Interest Group (SIG).