Kubernetes is a powerful tool. It can help you manage complex applications and provide you with the ability to easily automate tasks involved in managing them. In this course, we will start exploring Kubernetes from a beginner's standpoint. We will discuss what Kubernetes is and what it does, and we will work with some of the basic functionality of Kubernetes hands-on. We will build a simple Kubernetes cluster. We will also deploy a sample microservice application to the cluster in order to explore how Kubernetes can help easily manage such applications.

A Practical Guide to Kubernetes

## The Solution
The new request demanding more freedom provides an excellent opportunity to combine Namespaces with Role Bindings. 

We can create a `dev` Namespace and allow a selected group of users to do almost anything in it. That should give developers enough freedom within the `dev` Namespace while avoiding the risks of negatively impacting the resources running in others.
### Looking into the Definition
Let's take a look at the `auth/rb-dev.yml` definition.

apiVersion: v1
kind: Namespace
metadata:
  name: dev

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev
  namespace: dev
subjects:
- kind: User
  name: jdoe
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

**Line 1-4:** The first section defines the `dev` Namespace. 

**Line 8-20:** The second section specifies the binding with the same name. Since we're using `RoleBinding` (not `ClusterRoleBinding`), the effects will be limited to the `dev` Namespace. At the moment, there is only one subject (the User `jdoe`). We can expect the list to grow with time.

**Line 17-20:** `roleRef` uses `ClusterRole` (not `Role`) `kind`. Even though the Cluster Role is available across the whole cluster, the fact that we are combining it with `RoleBinding` will limit it to the specified Namespace.

The Cluster Role `admin` has an extensive set of resources and verbs, and the Users (at the moment only `jdoe`) will be able to do almost anything within the `dev` Namespace.

### Creating the Resources
Let's create the new resources.

# The Solution
The new request demanding more freedom provides an excellent opportunity to combine Namespaces with Role Bindings. 

We can create a `dev` Namespace and allow a selected group of users to do almost anything in it. That should give developers enough freedom within the `dev` Namespace while avoiding the risks of negatively impacting the resources running in others.
## Looking into the Definition
Let's take a look at the `auth/rb-dev.yml` definition.

**Line 1-4:** The first section defines the `dev` Namespace. 

**Line 8-20:** The second section specifies the binding with the same name. Since we're using `RoleBinding` (not `ClusterRoleBinding`), the effects will be limited to the `dev` Namespace. At the moment, there is only one subject (the User `jdoe`). We can expect the list to grow with time.

**Line 17-20:** `roleRef` uses `ClusterRole` (not `Role`) `kind`. Even though the Cluster Role is available across the whole cluster, the fact that we are combining it with `RoleBinding` will limit it to the specified Namespace.

The Cluster Role `admin` has an extensive set of resources and verbs, and the Users (at the moment only `jdoe`) will be able to do almost anything within the `dev` Namespace.

## Creating the Resources
Let's create the new resources.

In this lesson, first, we will combine Role Bindings with Namespaces and then create a user-specific Namespace.

Combining Role Bindings with Namespaces

The Solution

Looking into the Definition