sagikazarmark / curiefense-emissary-poc Goto Github PK

We need to figure out a build process for production images. A couple things to consider:

• Emissary support policy (how many versions do they support)?
• Curiefense support policy
• Emissary release cycle
• Curiefense release cycle

An optimal scenario: support the latest patch versions, two minor versions and all supported major versions of each. That would result in a matrix build, combining all support versions (minus all incompatible versions).

For example:

• Emissary supported versions: 2.3.x, 3.2.x
• Curiefense supported versions: 1.5.x, 1.6.x

Emissary 2.3.x and Curiefense 1.6.x are known NOT to work (eg. too old Envoy version, etc).

The build matrix would look like this:

• Emissary 2.3.x, Curiefense 1.5.x
• Emissary 2.4.x, Curiefense 1.5.x
• Emissary 2.4.x, Curiefense 1.6.x

Builds should be automated as much as possible (for example: use Dependabot for automatically updating and releasing patch versions)

Requires #8

References

• https://github.com/emissary-ingress/emissary/
• https://docs.curiefense.io/reference/release-notes

How can we use a custom (private) Git repository?

Emissary comes with two installation methods:

• Helm
• Kubernetes YAML / Kustomize

In order to make Curieproxy work, the following changes have to be made:

• the Module CR has to be extended with the necessary lua_scripts (note: this may change from version to version (Curiefense))
• the image should be changed to an image containing Curieproxy
• a sidecar container has to be added (Curiesync)
• an emptyDir volume has to be mounted to both containers (Emissary, Curiesync)

In addition to the above, the Curiesync container needs a ConfigMap or a Secret containing credentials to the config store bucket.

Also, a LogService CR can optionally be created to send logs to Curielogger (although this may change in 1.6).

The Kubernetes YAML method either requires patched YAML files, or use Kustomize (see this repo).

The Helm chart provides all the necessary extension points, so it should be a matter of documentation.

Keep in mind that Curieproxy also requires Redis for features, like rate limiting. The credentials and information for that has to be injeceted.....probably to the Curieproxy (Emissary) container?

The current deployment mechanism is using a Helm chart in https://github.com/curiefense/curiefense-helm

This is in no way suitable for a production environment:

• Chart is heavy with all kinds of dependencies usually not installed in a production environment (Prometheus, Grafana, Elasticsearch, Kibana, etc)
• Chart supports various environments which aren't necessary (eg. Istio)
• a Helm chart may not even be the right way to install these components (Kustomize might be better)

Make collab easier

We need to be able to prove that access to certain subregions is blocked, so we are going to need curiefense/curiefense#694

We could use the LogService CRD of Emissary to configure envoy to send logs to curielogger: https://www.getambassador.io/docs/emissary/latest/topics/running/services/log-service/

I have no idea though if this comes after the requests are passed through Curiefense or not, so it may require some help from Emissary.

• Lua scripts filter ordering: ideally Curiefense should always come first. Is that currently possible?
• LogService: are requests logged after going through all filters (lua included)?

In the Kubernetes world a common pattern for collecting and forwarding logs is using FluentBit and Fluentd:

• Drop filebeat
• Mark access logs with a marker, so Fluentd can route them accordingly

This may not be an issue once Curiefense 1.6 is out.

Create a Dockerfile that contains the minimal files and build steps required for a production image.

I suspect Curiefense (proxy) expects the curielogger component to be in the same namespace (at least I vaguely remember that I had to install nginx ingress in the same namespace as curiefense back when I tried it last time).

How is the MaxMind database handled at the moment? Is it updated? If so, how?

Do we need a custom update process?