This is a beta release. This product might be changed in backward-incompatible ways and is not subject to any SLA or deprecation policy.
This page describes the architecture of Forseti when deployed on the Google Kubernetes Engine (GKE).
In a traditional Forseti installation, the compute resources are deployed as GCE virtual machines (VM). The Forseti server VM executes the forseti_server process, listening for requests to take action. On the Forseti server is also a Linux cronjob that periodically invokes the server to build inventory and a model, scan, and notify on any violations. The Forseti client VM provides a CLI where a user can invoke these same functions as well as execute the IAM explain function.
In Forseti on-GKE, the core compute resources are deployed in containers: the server and orchestrator. These containers are each wrapped in Kubernetes Pods; the forseti-server and forseti-orchestrator pods respectively.
The forseti-server pod is deployed in a Kubernetes Deployment controller. Like the forseti_server process on the VM, this is a long running process that listens for requests made to it by a client.
The forseti-orchestrator pod is deployed in a Kubernetes CronJob. This reflects the behavior of the Linux cronjob on the server VM, periodically invoking the inventory build, scan, and notification actions on the forseti-server deployment.
The config-validator pod is also deployed in a Kubernetes Deployment controller. The service provided by the config-validator pod is exposed internally to Forseti on-GKE. The Config Validator Scanner uses this service when auditing resources against a policy-library. The config-validator uses git-sync in a container to periodically pull a policy-library in from a Git repository. If a change in the policies is detected, git-sync will make a call to the kube-proxy container to restart the pod with the updated policies.
The client CLI is still provided through the GCE VM. The endpoint configuration for the the VM is set to send requests to the GCP load balancer for the Forseti server deployment.
This is illustrated in the following diagram.
The container images can be found in the following repositories
The following describes the container image tags used in a Forseti on-GKE installation.
|With each release of Forseti, a new container image is built with a tag corresponding to a tag in GitHub. The latest release is also tagged with :latest.|
|master||Every time a pull request is merged into the master branch in GitHub, a new container image build is triggered resulting in an image with the :master tag.|
Forseti Security employs multi-stage builds wherever possible for example the forseti image. With multi-stage builds, container images can be built where the build-time dependencies are not necissarily present in the runtime container image. The result is a smaller image for deployment. The following image and chart describe each of the container image layers defined by the Dockerfile
Helm is a package and application manager for Kubernetes. Forseti uses Helm charts to manage the installation and upgrade of the Forseti application. The Forseti Helm charts only deploy the Forseti Server and Forseti Orchestrator containers. The Helm charts do not deploy the other components of Forseti (e.g. CloudSQL, GCS).