-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Charles-Edouard Brétéché <charles.edouard@nirmata.com>
- Loading branch information
1 parent
dd31f6f
commit 253909b
Showing
5 changed files
with
231 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
# Quick start | ||
|
||
The Kyverno Envoy Plugin is a powerful tool that integrates with the Envoy proxy. | ||
|
||
It allows you to enforce Kyverno policies on incoming and outgoing traffic in a service mesh environment, providing an additional layer of security and control over your applications. | ||
|
||
## Overview | ||
|
||
[Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy) is a Layer 7 proxy and communication bus tailored for large-scale, modern service-oriented architectures. Starting from version 1.7.0, Envoy includes an [External Authorization filter](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ext_authz_filter.html) that interfaces with an authorization service to determine the legitimacy of incoming requests. | ||
|
||
This functionality allows authorization decisions to be offloaded to an external service, which can access the request context. The request context includes details such as the origin and destination of the network activity, as well as specifics of the network request (e.g., HTTP request). This information enables the external service to make a well-informed decision regarding the authorization of the incoming request processed by Envoy. | ||
|
||
## What is the Kyverno Envoy Plugin? | ||
|
||
The [Kyverno Envoy Plugin](https://github.com/kyverno/kyverno-envoy-plugin) is gRPC server that implements [Envoy External Authorization API](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ext_authz_filter.html). | ||
|
||
This allows you to enforce Kyverno policies on incoming and outgoing traffic in a service mesh environment, providing an additional layer of security and control over your applications. You can use this version of Kyverno to enforce fine-grained, context-aware access control policies with Envoy without modifying your microservice. | ||
|
||
## How does this work? | ||
|
||
In addition to the Envoy sidecar, your application pods will include a Kyverno Authz Server component, either as a sidecar or as a separate pod. When Envoy receives an API request intended for your microservice, it consults the Kyverno Authz Server to determine whether the request should be permitted or not. | ||
|
||
Performing policy evaluations locally with Envoy is advantageous, as it eliminates the need for an additional network hop for authorization checks, thus enhancing both performance and availability. | ||
|
||
!!! info | ||
|
||
The Kyverno Envoy Plugin is frequently deployed in Kubernetes environments as a sidecar container or as a separate pod. Additionally, it can be used in other environments as a standalone process running alongside Envoy. | ||
|
||
## Additional Resources | ||
|
||
See the following pages on [envoyproxy.io](https://www.envoyproxy.io/) for more information on external authorization: | ||
|
||
- [External Authorization](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ext_authz_filter.html) to learn about the External Authorization filter. | ||
- [Network](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/ext_authz_filter#config-network-filters-ext-authz) and [HTTP](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter#config-http-filters-ext-authz) for details on configuring the External Authorization filter. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,186 @@ | ||
# Installation | ||
|
||
## Setup | ||
|
||
In this quick start guide we will deploy the Kyverno Authz Server in a standalone mode inside the cluster. | ||
|
||
### Prerequisites | ||
|
||
- A Kubernetes cluster with Istio installed | ||
- [Helm](https://helm.sh/) to install the Kyverno Authz Server | ||
- [istioctl](https://istio.io/latest/docs/setup/getting-started/#download) to configure the mesh | ||
- [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) to interact with the cluster | ||
|
||
### Setup a cluster (optional) | ||
|
||
If you don't have a cluster at hand, you can create a local one with [kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) and istall Istio with Helm. | ||
|
||
```bash | ||
KIND_IMAGE=kindest/node:v1.31.1 | ||
|
||
# create cluster | ||
kind create cluster --image $KIND_IMAGE --wait 1m | ||
|
||
# install istio | ||
helm install istio-base --namespace istio-system --create-namespace --wait --repo https://istio-release.storage.googleapis.com/charts base | ||
helm install istiod --namespace istio-system --create-namespace --wait --repo https://istio-release.storage.googleapis.com/charts istiod | ||
``` | ||
|
||
### Deploy the Kyverno Authz Server | ||
|
||
The first step is to deploy the Kyverno Authz Server. | ||
|
||
```bash | ||
# create the kyverno namespace | ||
kubectl create ns kyverno | ||
|
||
# label the namespace to inject the envoy proxy | ||
kubectl label namespace kyverno istio-injection=enabled | ||
|
||
# deploy the kyverno authz server | ||
helm install kyverno-authz-server --namespace kyverno --wait --repo https://kyverno.github.io/kyverno-envoy-plugin kyverno-authz-server | ||
``` | ||
|
||
### Configure the mesh | ||
|
||
We need to register the Kyverno Authz Server with Istio. | ||
|
||
```bash | ||
# configure the mesh | ||
istioctl install -y -f - <<EOF | ||
apiVersion: install.istio.io/v1alpha1 | ||
kind: IstioOperator | ||
spec: | ||
meshConfig: | ||
accessLogFile: /dev/stdout | ||
extensionProviders: | ||
- name: kyverno-authz-server.local | ||
envoyExtAuthzGrpc: | ||
service: kyverno-authz-server.kyverno.svc.cluster.local | ||
port: '9081' | ||
EOF | ||
``` | ||
|
||
Notice that in the configuration, we define an `extensionProviders` section that points to the Kyverno Authz Server installation: | ||
|
||
```yaml | ||
[...] | ||
extensionProviders: | ||
- name: kyverno-authz-server.local | ||
envoyExtAuthzGrpc: | ||
service: kyverno-authz-server.kyverno.svc.cluster.local | ||
port: '9081' | ||
[...] | ||
``` | ||
|
||
### Deploy a sample application | ||
|
||
Httpbin is a well-known application that can be used to test HTTP requests and helps to show quickly how we can play with the request and response attributes. | ||
|
||
```bash | ||
# create the demo namespace | ||
kubectl create ns demo | ||
|
||
# label the namespace to inject the envoy proxy | ||
kubectl label namespace demo istio-injection=enabled | ||
|
||
# deploy the httpbin application | ||
kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n demo | ||
``` | ||
|
||
### Deploy an Istio AuthorizationPolicy | ||
|
||
An `AuthorizationPolicy` is the custom Istio resource that defines the services that will be protected by the Kyverno Authz Server. | ||
|
||
```bash | ||
# deploy istio authorization policy | ||
kubectl apply -f - <<EOF | ||
apiVersion: security.istio.io/v1 | ||
kind: AuthorizationPolicy | ||
metadata: | ||
name: kyverno-authz-server | ||
namespace: demo | ||
spec: | ||
action: CUSTOM | ||
provider: | ||
name: kyverno-authz-server.local | ||
EOF | ||
``` | ||
|
||
Notice that in this resource, we define the Kyverno Authz Server `extensionProvider` you set in the Istio configuration: | ||
|
||
```yaml | ||
[...] | ||
provider: | ||
name: kyverno-authz-server.local | ||
[...] | ||
``` | ||
|
||
### Deploy a Kyverno AuthorizationPolicy | ||
|
||
A Kyverno `AuthorizationPolicy` defines the rules used by the Kyverno authz server to make a decision based on a given Envoy [CheckRequest](https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto#service-auth-v3-checkrequest). | ||
|
||
It uses the [CEL language](https://github.com/google/cel-spec) to analyse the incoming `CheckRequest` and is expected to produce a [CheckResponse](https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto#service-auth-v3-checkresponse) in return. | ||
|
||
```bash | ||
# deploy kyverno authorization policy | ||
kubectl apply -f - <<EOF | ||
apiVersion: envoy.kyverno.io/v1alpha1 | ||
kind: AuthorizationPolicy | ||
metadata: | ||
name: demo | ||
spec: | ||
failurePolicy: Fail | ||
variables: | ||
- name: force_authorized | ||
expression: object.attributes.request.http.?headers["x-force-authorized"].orValue("") | ||
- name: allowed | ||
expression: variables.force_authorized in ["enabled", "true"] | ||
authorizations: | ||
- expression: > | ||
variables.allowed | ||
? envoy.Allowed().Response() | ||
: envoy.Denied(403).Response() | ||
EOF | ||
``` | ||
|
||
This simple policy will allow requests if they contain the header `x-force-authorized` with the value `enabled` or `true`. | ||
If the header is not present or has a different value, the request will be denied. | ||
|
||
## Testing | ||
|
||
At this we have deployed and configured Istio, the Kyverno Authz Server, a sample application, and the authorization policies. | ||
|
||
### Start an in-cluster shell | ||
|
||
Let's start a pod in the cluster with a shell to call into the sample application. | ||
|
||
```bash | ||
# run an in-cluster shell | ||
kubectl run -i -t busybox --image=alpine --restart=Never -n demo | ||
``` | ||
|
||
### Install curl | ||
|
||
We will use curl to call into the sample application but it's not installed in our shell, let's install it in the pod. | ||
|
||
```bash | ||
# install curl | ||
apk add curl | ||
``` | ||
|
||
### Call into the sample application | ||
|
||
Now we can send request to the sample application and verify the result. | ||
|
||
The following request will return `403` (denied by our policy): | ||
|
||
```bash | ||
curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get | ||
``` | ||
|
||
The following request will return `200` (allowed by our policy): | ||
|
||
```bash | ||
curl -s -w "\nhttp_code=%{http_code}" httpbin:8000/get -H "x-force-authorized: true" | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
# Next steps | ||
|
||
TODO |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters