Using Kubernetes TLS Ingress with Platform9 Fission FaaS endpoints

As FaaS offerings find more and more use-cases for function-compatible workflows, the requirements to become production-ready is a list that almost feels like it will never end. In a large enough enterprise, a lot of things will happen upstream of your Kubernetes cluster (lots and lots of hardware, for example; firewalls, routers, etc.), but the granular control over cluster interactivity still has a place in the discussion at any scale (and in particular if you handle any kind of sensitive data).

With this in mind, using things like NetworkPolicy objects, RBAC, and the secret management flow, and in the case of our goal here, the TLS features available to an ingress, making your workloads more closely meet the needs of a production deployment have never been more easy to be declarative about the way you are with any resource in the cluster. An example that stands out to me, in particular, is securing Internet-facing (there are other options for cluster-facing endpoints) workloads in FaaS systems like Fission from Platform9.

This example won’t be comprehensive, but perhaps will provide some insight into how native Kubernetes functionality can enhance software that is backed by Kubernetes, but may not have default behavior (i.e. running a task only requires thefission CLI, and optionally you might dig into Kubernetes for other options) that requires it in order to be usable.

What’re we making?

Securing your Fission router endpoint is a relatively straight forward task, so we will demonstrate:

  1. Creating secrets for your TLS cert and key.
  2. Creating an Ingress with TLS enabled.
  3. Running the task through this secure channel.


The Kubernetes secrets workflow is a very neat component, and we’ll be using it here to store, and recall our certificate and key data, which are both stored as a base64-encoded string.

cat cert.crt | base64
cat cert.key | base64

and you’ll add those values to your YAML config:

apiVersion: v1
kind: Secret
name: router-tls
namespace: fission
type: Opaque

To create this secret, and expose it to the fission namespace, you’ll apply it like you might anything else:

jmarhee: ~ 💅  kubectl create -f tls.yaml
secret "router-tls" created


Making use of the secret when you create the ingress is pretty straightforward:

apiVersion: extensions/v1beta1
kind: Ingress
name: fission-tls
namespace: fission
annotations: "nginx" /
- hosts:
- secretName: router-tls
- backend:
serviceName: router
servicePort: 80
path: /fission

Create the ingress:

jmarhee: ~ 💅  kubectl create -f router-ingress.yaml
ingress "fission-tls" created

So, what this does is:

  1. Accesses the secret (you can restrict this usage further, of course, and limit it to users you want to scope access for with RBAC)
  2. Creates a rule that requests for `${YOUR_COMMON_NAME}` (whatever it is for the certificates), are routed to your fission router on the path /fission

Which creates a TLS-protected interface to your FISSION_ROUTER (which you can reset to use HTTPS):

jmarhee: ~ 💅  export FISSION_URL=https://${YOUR_COMMON_NAME}
jmarhee: ~ 💅 export FISSION_ROUTER=https://${YOUR_COMMON_NAME

to create and manage your existing jobs, but now, also to access them:

jmarhee: ~ 💅  curl https://${YOUR_COMMON_NAME}/fission/hello 
Hello, world!

Moving Forward

This example just used a cert I created just for the demonstration, but there’s much more you can do regarding management of TLS certificates in Kubernetes:

and the Ingress resource has a lot of different use cases and applications, and as always, I recommend taking look through the documentation if you think this example gives you an idea of what benefit these features might bring:

I also mentioned that Role-Based Access Control(RBAC) can be used here:

With the goal in mind of restricting usage of this secret in certain namespace, and for certain users.