kube_shields 0.0.6
kube shields flask frontend.

# Kube-shields

Redirection service to shields.io for inside a Kubernetes cluster. Uses the
Kubernetes API with the service account token and ca.crt injected to
`/var/run/secrets/kubernetes.io/serviceaccount/` in the running container.


# Configuration

## `OTHER_SHIELDS`

Kube-shields can be run with public access or without. This is dictated by
whether or not the `OTHER_SHIELDS` environment variable is set. You can enable
public access to the all endpoints by setting this value to a DNS name or IP
address of another kube-shield in another cluster. If you only have one cluster
and you want it to have public access, set the value to "None". If a kube-shields
server does not have the `OTHER_SHIELDS` env var set, it will only communicate
to other kube-shields servers sharing the same secret key.

## `SHIELD_SITE_NAME`

The `SHIELD_SITE_NAME` is only used for the `/` route, and thus only required
if the `OTHER_SHIELDS` variable is also set. It will be displayed in the main
html as the page title, and used for the shields' hovertext.

## `INTRA_SECRET`

This must be set on all kube-shield servers. The default is to use part of the
python package itself, which is in no way secure. You should generate a file
to be used as your shared secret and update the `INTRA_SECRET` env var to it's
filepath. If your intra-shield traffic is captured unencrypted it is possible
given enough time to brute force your secret key. This can be mitigated by
using a lengthy key and/or rotating them regularly.


# Automatic Discovery

Any Kubernetes Pod running in the same cluster as the kube-shield service and
also created automatically via some other object such as a ReplicationController
or DaemonSet will be found and have a health check generated for it. The check
is relatively simple, only returning the number of ready containers vs total,
with any discrepancy resulting in a red result instead of green. It also checks
each pod to see if it has restarted more than once every other day. If so,
the result will be yellow.


# Custom Checks

Making a custom check should be simple. You can create a python file with the
name of the pod you would like to apply the check to. In that file, create all
the helper functions you need, but be sure to prefix them with a `_`. The
functions that don't begin with an underscore will be used as custom checks for
that pod. The return format can either be a raw value, or you can return a dict
with the keys `label`, `status`, and `color`.

Caveat: do not name a custom check named `health`, it will be inaccessible.


# API

## `/`

`/` is available only if `OTHER_SHIELDS` is set. `/` will return HTML with a
list of all the service and their checks in all the clusters. There is no
caching anywhere in kube-shields though, keep that in mind.

## `/_/<pod>/<check>/`

The `_` endpoint is for retrieving a specific pod and check's result shield.
The automatically generated check is available under the check name `health`.
Your custom checks are available under their function names.

## `/a/<name>/<check>/`

The `a` endpoint is used to aggregate similarly named pods, as long as they have
the check, into the same shield result. The name section is the leading part of
pod name. For instance, the endpoint `/a/foo/health/` can be used to combine
the output for the pods `foo-bar`, `foo-baz`, and `foo` into a single shield.

## `/services/`

Typically only used with intra-shield traffic, returns a JSON list of all
discovered services. Requires intra-shield authentication if `OTHER_SHIELDS`
is not set.

## `/services/<name>/`

Also typically only used in intra-shield communication, this returns a JSON
list of all checks available for the named service, or 404.