
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.

For Whom Is This Blog For?


<small>Co-Written by [Lailo](https://lailo.ch)</small>

We built [500error.co](https://www.500error.co) because we had to solve one of our problems. The idea was first pitched on [Pitchcard.io](https://www.pitchcard.io) and got a lot of traction. So we decided to built it, and we did it in less than two weeks.

# How It Started

We ([Susana Garcia](https://susana.dev) and I) like to build things. We don’t like to talk about how cool it would be to do this and that — we just do it. The outcome is that we have a lot of projects simultaneously.

As we all know, servers can crash and “oooh boy they do”. And you know what, they crash at the worst time. They crash while your release and you lose important leads. Or they crash while you sleep and we really like to sleep 💤. We decided to fix this problem.

# Developing in Bratislava

We’re digital nomads and we moved to a new city every other month, but that’s another story. For this month, we’re in Bratislava.

We used our very first day in Bratislava to collect all feedback from Pitchcard.io, friends and other developers. We picked the most important features for a MVP.

We used the second day to choose the right tools to built this, and ended up using NodeJS with Express for the backend and React for the front end, as we had already positive experiences with these tools building [Pitchcard.io](https://www.pitchcard.io).

From day three up to day seven, we built the MVP and send some invite emails to the investors of [Pitchcard.io](https://www.pitchcard.io). They liked the simplicity and gave us really good feedback, what we could improve and what they were missing.

We used the second week to improve the UI for mobile, tablet and desktop. We also added a simple subscription with [Stripe](https://medium.com/u/3ecae35d6d66) (we really like Stripe). And we added better documentation of how to integrate it into Heroku, GitHub Pages and more.

# Customize Your Page

Our beta users like the way they could customize their error pages. They like it because it’s simple and funny. Here is what some things you can customize:

- Add your own brand color
- Choose one of the funny GIFs or just add your own Logo
- Define your title and description so it sounds like you

# The Result

We’re happy that our beta users liked the first version and we’re proud of what we could built in less than two weeks.

Now we can sleep at night without worrying about a crash on all these projects. If a server crash happens, we can fix it the day after and notify the new subscribed users. It’s simple as that.

Do you want to be able to sleep at night without worrying about your server? [Visit **500error.co**](https://www.500error.co), create your own error page, integrate it into your existing projects and have one less thing to worry about.


We built 500error.co because we had to solve one of our own problems.

500 Error


<small>Co-Written by [Lailo](https://lailo.ch)</small>

Since the iPhone released and the following AppStore boom, a lot of people around us began to have amazing ideas: “Hey, I have a really cool idea for a new app!”. Every single one of them thought, they had the next billion dollar idea.

# Get to the Point

They usually tried to explain it in a very complex way or sent us very long emails. As we both don’t like emails, long emails even less, we told most people to get to the point.

We believe that every good idea needs to be pitched in _2–3 sentences._ And this is only possible if you exactly know what the goal of your idea is.

# Share Your Idea

There are another few things that some people don’t know about good ideas.

Some people don’t talk much about their idea to protect it. They are afraid of someone stealing it. Fact is, **the more you share your idea, the better it gets.** Each time you explain your idea to people, they’ll ask you questions. First you won’t have an answer but it will force you to rethink your idea.

Another important thing is, what for you might be a pretty good idea, others wouldn’t even use it. And _what’s the point of creating something no one will ever use?_ Evaluate your idea first, then decide to build it or to move on.

# Quick Feedback

That’s why we’ve built [Pitchcard.io](https://www.pitchcard.io/) to get quick feedback. We’ve picked this name because of the elevator pitch.

> “\[..\] the idea that it should be possible to deliver the summary in the time span of an elevator ride, or approximately thirty seconds \[..\]”

## How it works

1.  Visit [www.pitchcard.io](https://www.pitchcard.io/)
2.  Create your _Pitchcard_
3.  Share it

We know that ideas can pop up anytime and anywhere (having lunch, doing sport or meeting up with friends). That’s why we made it very easy to create a _Pitchcard._

You can share your _Pitchcard_ with close friends via WhatsApp and email, or with everyone via Facebook, Twitter or others.

Another important point of _Pitchcard_ is, that we consequently set a **200 chars limit on the description** of the idea**.** As we already mentioned before, we want that people get to the point.

We hope you like our product and wish you good luck with your next billion dollar idea. 😜


Since the iPhone released and the following AppStore boom, a lot of people began to tell us: "Hey, I have an app idea...".

Don't miss out.