In this tutorial we will learn about Alcide Embedded Firewall Policies.
Alcide Embedded Firewall Policies basically enable developers & devops to capture their microservice know-how into a set of firewall rules that creates a whitelisted perimeter at the Pod level.
The policy embedding, comes in the shape and form of annotating Pod Specification within a deployed resource.
So whether this a plain Kubernetes YAML resource, a helm chart, we can capture security policy as code.
Alcide Embedded Policies are created by developers/devops either in Git or as part of an automation pipeline to control the "Allowed" network traffic for the application/micro-service.
By using Alcide Embedded Policies, new applications are immediately granted with the required access to operate, and only what's required.
For this tutorial you will need a Kubernetes cluster with enough permissions to deploy resources into it.
In order to implement Alcide Runtime Security features, we will need to onboard your Kubernetes cluster into your Alcide Cloud Account
At this point you should be able to see your cluster, worker nodes, and workloads, in the Infrastructure View and the application components in your Application View
Let's begin with few Alcide Embedded Policy examples before we see the syntax definiton:
policy.alcide.io/inbound0: tcp://10.0.2.14:80 policy.alcide.io/inbound1: service://somenamespace.someservice policy.alcide.io/outbound0: service://kafka policy.alcide.io/outbound1: https://hosted.db.service.cloudprovider.com
The formal syntax of Alcide Embedded Policy is composed of one or more policy rules:
policy.alcide.io/<Traffic direction><Rule number> <Rule>
A rule could be based on an IP, DNS or a service. To define the rule type, edit the rule type section of your policy.
A rule on IP or DNS is defined in the following structure:
A rule on a service is defined in the following structure: service://[namespace.]service|any
namespace If not specified, any namespace will be matched.
service The service on which the rule is based on. The default service port will be taken if not specified otherwiseUse "any" to allow access on any service.
There is no service in IP/DNS rule.
I suggest to split the explanation about L3 & L4 protocols.
With L3 protocol, port is mandatory!
With L4 protocol, port is optional. You can only specify the default port OR any. You'll not be able to specify any other specific port.
Create the frontend, backend, and client apps:
kubectl create -f https://raw.githubusercontent.com/alcideio/codelab/master/docs/codelabs/runtime-codelab-03/alcide-demo_namespace.yaml kubectl create -f https://raw.githubusercontent.com/alcideio/codelab/master/docs/codelabs/runtime-codelab-03/star_demo.yaml
We are going to switch Alcide's Agent running mode - enforcement mode.
kubectl set env daemonsets/agent-nodelet -n alcide ALCIDE_WORKLOAD_ENFORCE_MODE=inline && kubectl rollout status -n alcide daemonset/agent-nodelet --watch && while [[ ! $(kubectl -n alcide exec -it $(kubectl get pods -n alcide -l app=agent-nodelet -o custom-columns=:metadata.name --no-headers) -- alcide_agent dp wl ls | grep $(kubectl get pods -n alcide-demo -l app=client -o custom-columns=:metadata.name --no-headers)) ]]; do echo "please wait for Alcide agent to be reaady..."; sleep 20; done; echo "Ready! :)"
Now let's create the same workload but this time with Alcide Embedded Firewall Policies:
kubectl create -f https://raw.githubusercontent.com/alcideio/codelab/master/docs/codelabs/runtime-codelab-03/star_demo_with_embedded_policies.yaml
Delete the alcide-demo Deployment from the previous step and re-deploy it.
kubectl delete -f https://raw.githubusercontent.com/alcideio/codelab/master/docs/codelabs/runtime-codelab-03/star_demo_with_embedded_policies.yaml kubectl delete -f https://raw.githubusercontent.com/alcideio/codelab/master/docs/codelabs/runtime-codelab-03/star_demo.yaml kubectl delete -f https://raw.githubusercontent.com/alcideio/codelab/master/docs/codelabs/runtime-codelab-03/alcide-demo_namespace.yaml
In this codelab we covered: