
By default no access is granted to applications in Kubernetes. So we have to explicitly allow access to the parts of the API that your applications need.

Kubernetes includes a built-in role-based access control (RBAC) mechanism that enables you to configure specific sets of permissions that define how a given user (or group of users) can interact with any Kubernetes object in a specific Namespace of your cluster.

The RBAC API declares four kinds of Kubernetes object: Role, ClusterRole, RoleBinding and ClusterRoleBinding. In this article, I'll focus on Role and RoleBinding.

# How can we grant access to the Kubernetes API?

Kubernetes provides two resources that control the access to the API:

* Role: specifies what access is granted (set of permissions). When we create a Role, we need to specify the Namespace it belongs in.
* RoleBinding: specifies who the Role applies to (links a Role to subjects). 

# Create a Role

Here is a yaml configuration file you can use to create a `Role` that let us list the pods and get information on a particular pod:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-role
  namespace: my-namespace
  labels:
    app: my-rbac-app
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "list"] # verbs to act on the that resource
```

A Role in isolation doesn't do anything until we bind it with a RoleBinding, so let's do that in the next step.

# Create a RoleBinding

Here is a yaml configuration file you can use to create a `RoleBinding` that give this role ("my-role") to all service accounts in the default namespace, meaning that all pods will have access to these APIs:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in "my-namespace" namespace.
# You need to already have a Role named "my-role" in that namespace.
kind: RoleBinding
metadata:
  name: my-rolebinding
  namespace: my-namespace
  labels:
    app: my-rbac-app
subjects:
# You can specify more than one "subject"
- kind: Group
  name: system:serviceaccounts # "name" is case sensitive
  apiGroup: rbac.authorization.k8s.io
  namespace: my-namespace
roleRef:
  # "roleRef" specifies the binding to a Role
  kind: Role #this must be Role
  name: my-role # this must match the name of the Role you wish to bind to
  apiGroup: ""
```

# Create a Service Account

The best practice in security is to give as few permissions as possible. Kubernetes recommends to grant a role to an application-specific service account. This requires the application to specify a `serviceAccountName` in its pod spec and for the service account to be created.

Here is a yaml configuration file you can use to create a basic `ServiceAccount`:

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: my-namespace
  labels:
    app: my-rbac-app
```

We can start a pod with a `ServiceAccount` by adding that to it's spec definition:

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  namespace: my-namespace
  labels:
    app: my-app
    rbac: my-service-account
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
      namespace: my-namespace
      rbac: my-service-account
  template:
    metadata:
      labels:
        app: my-app
        namespace: my-namespace
        rbac: my-service-account
    spec:
      serviceAccountName: my-service-account
      containers:
        - name: my-container
          image: nginx:1.7.9
```

In the pod spec you can see `serviceAccountName: my-service-account`. The pod will be run as this `ServiceAccount` and all containers started from it will be running under that `ServiceAccount`.

Last step is to apply all yaml files in the repository:

```bash
$ kubectl apply -f my-role.yaml -f my-rolebinding.yaml -f my-serviceaccount.yaml -f my-deployment.yaml -n my-namespace
```

For more information related to RBAC Authorization, please check the [Kubernetes documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).


Learn how to Grant Access to the Kubernetes API.

How to Grant Access to the Kubernetes API


Kubernetes Secrets let you store and manage sensitive information like as passwords, OAuth tokens, ssh keys, etc. 

With this article, you'll learn how to use them easily.

# What is a Secret in Kubernetes?

A secret is an object that contains sensitive information like passwords, keys, tokens...

To use it, a Pod needs to reference it:
* As files in a volume mounted on one or more of its containers.
* By the `kubelet` when pulling images for the Pod.

# Optimal way to create and mount a Secret

For me the easiest way to use Secrets is defining a YAML and reference them using `envFrom/secretRef`.

1. Here is a yaml configuration file you can use to create a Secret that holds a username and a password:

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  username: my-username
  password: vdg7JbgkdnRnN03e
```

2. Reference the Secret (my-secret-pod.yaml):

```yaml
kind: Pod
apiVersion: v1
metadata:
  name: my-secret-pod
  namespace: my-namespace
spec:
  containers:
    - name: my-container
      image: nginx:1.7.9
      envFrom:
        - secretRef:
            name: my-secret
```

3. Then you just need to create the Pod:

```bash
$ kubectl apply -f my-secret-pod.yaml -n my-namespace
```

For more information related to Secrets, please check the [Kubernetes documentation](https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/).


Learn how to use Secrets in Kubernetes with some examples.

How to Use Secrets in Kubernetes


When starting to use a new technology, one of the first questions to answer is how to manage your application's configuration. In the Kubernetes world, that answer is ConfigMaps.

With this article, you'll learn how to use them.

# What is a ConfigMap?

A ConfigMap is a dictionary composed of by a key-value pairs of strings.
It basically stores (public) configuration settings for your code. If you want to store secret configuration settings, you'll need to store them in another manner.

# How ConfigMaps are deployed

1. You have ConfigMap/s for every environment.
2. A ConfigMap is created and added to a Kubernetes cluster.
3. Containers in a Pod reference the ConfigMap to use its values.

# Optimal way to create and mount a ConfigMap

For me the best way to use ConfigMaps is defining a YAML and reference them using `envFrom/configMapRef`.

## Here is an example of a ConfigMap in a YAML file

```yaml
kind: ConfigMap
apiVersion: v1
metadata:
  name: env-vars-configmap
  namespace: my-namespace
data:
  # Configuration values as key-value properties where value is a string
  base_url: https://my.website.dev/
  database_port: "3306"

  # Also you can read those values from variables
  base_url: ${BASE_URL}
  database_port: "${DATABASE_PORT}"

  # Or set as file contents
  file_keys: |
    color.good=purple
    color.bad=yellow
```

To added it to your namespace in the Kubernetes cluster:

```bash
$ kubectl apply -f env-vars-configmap.yaml -n my-namespace
```

Also you can see the values of the environment variables executing:

```bash
$ kubectl get configmap -n my-namespace env-vars-configmap.yaml -o yaml
```

_Tip: this last command is useful when you have errors in the ConfigMap. If you use variables, try replace them with the real values and see which one fails._

## Reference the ConfigMap

Set the `envFrom/configMapRef` in each container to an object containing the list of ConfigMaps you want to include.

```yaml
kind: Pod
apiVersion: v1
metadata:
  name: pod-configmap
  namespace: my-namespace
spec:
  containers:
    - name: my-container
      image: nginx:1.7.9
      envFrom:
        - configMapRef:
            name: env-vars-configmap
```

Attach to the created Pod using:

```bash
$ kubectl exec -it pod-configmap sh
```

Then run `env` and see that all keys are now available as environment variables.

For more information related to ConfigMaps, please check the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/).


Learn how to use ConfigMaps in Kubernetes with some examples.

How to Use ConfigMaps in Kubernetes


## 1. Clone your forked project

This is only important if it's not yet in your workspace

```bash
git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-PROJECT.git
```

## 2. Add remote from original repository in your forked one

```bash
cd into/cloned/forked-project
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/PROJECT-YOU-FORKED-FROM.git
git fetch upstream
```

## 3. Updating your forked project from the original one to have their changes

```bash
git pull upstream master
```

## 4. Solve conflicts (if any)

## 5. Finally push changes

```bash
git push
```


Learn how to get changes committed to a project you forked.

How to Get Changes from Forked Project


As developers, we are learning new things every day.

In this blog I want to share what I'm currently learning, but also what I've learned.

So if you want to know more about the development of APIs and machine learning, from a developer with more than 10 years of experience, please follow me on Twitter, subscribe to my newsletter or to my RSS feed.

Special thank you to Lailo and his [open source code](https://github.com/lailo/next-with-tailwindcss) that I used for this blog.


Learn about this blog and if it's for you.

#code

Don't miss out.