chen-keinan/mesh-kridikAutomated security checker for Kubernetes clusters with Istio service mesh, enforcing best practices via OPA policies and generating remediation reports for misconfigurations.
Enhance your Kubernetes service mesh security !!
mesh-kridik is an open-source security checker that performs various security checks on a Kubernetes cluster with istio service mesh and outputs a security report
The security checks tests are the full implementation of istio security best practices
The security checks performed on a Kubernetes cluster with istio service mesh and is leveraged by OPA (Open Policy Agent) to enforce security rules, and the output audit report includes: the root cause of the security issue and proposed remediation for the security issue.
git clone https://github.com/chen-keinan/mesh-kridik
cd mesh-kridik
make build
Execute Mesh-Kridik without any flags , execute all tests
./mesh-kridik
Execute mesh-kridik with flags , execute test on demand
Usage: mesh-kridik [--version] [--help] <command> [<args>]
Available commands are:
-r , --report : run security checks and generate remediation report
-i , --include: execute only specific security check, example -i=1.1
-e , --exclude: ignore specific security check, example -e=1.1,2.0
Execute tests and generate failure tests report and it remediation's
./mesh-kridik -r
The Kube-kridik expose a hook for user plugins Example :
go build -buildmode=plugin -o=~/<plugin folder>/<plugin>.so ~/<plugin folder>/<plugin>.go
cp ~/<plugin folder>/<plugin>.so ~/.kube-kridik/plugins/compile/<plugin>.so
The Kube-kridik support this specifications and can be easily extended:
this specs can be easily extended by amended the spec files under ~/.mesh-kridik/security/mesh/istio folder
| Name | Description | Impact |
|---|---|---|
| Mutual TLS | Istio Mutual TLS proxies are configured in permissive mode by default | proxies will accept both mutual TLS and plaintext traffic |
| Istio Safer Authorization Policy Patterns | Use ALLOW-with-positive-matching or DENY-with-negative-match patterns | These authorization policy patterns are safer because the worst result in the case of policy mismatch is an unexpected 403 rejection instead of an authorization policy bypass. |
| path normalization in authorization policy | The enforcement point for authorization policies is the Envoy proxy instead of the usual resource access point in the backend application | A mismatch can lead to either unexpected rejection or a policy bypass |
| TLS origination for egress traffic | Use of DestinationRule on service ServiceEntry for egress traffic | Not using TLS origination for egress traffic to an external service will be send with plain/text |
| Protocol detection | explicitly declare the service protocol | miss detection may result in unexpected traffic behavior |
| CNI support | istio transparent traffic capture | not al net traffic will not be capture |
| overly broad hosts | avoid overly broad hosts settings in Gateway | may cause potential exposure of unexpected domains |
| Restrict Gateway creation privileges | restrict creation of Gateway resources to trusted cluster administrators | may cause creation of gateway by untrusted users |
| Configure a limit on downstream connections | Update global_downstream_max_connections in the config map according to the number of concurrent connections needed by individual gateway instances in your deployment. Once the limit is reached, Envoy will start rejecting tcp connections | no limit on the number of downstream connections can cause exploited by a malicious actor |
| Configure third party service account tokens | It is recommended to configure 3rd party tokens Because the properties of the first party token are less secure | first party token properties are less secure and might cause authentication breach |
| Control Plane | Istiod exposes a few unauthenticated plaintext ports for convenience by default | exposes the XDS service port 15010 and debug port 8080 over unauthenticated plaintext |
| Data Plane | The proxy exposes a variety of ports | The applications running in the same pod as the proxy have access; there is no trust boundary between the sidecar and application |
| Understand traffic capture limitations | Securing egress traffic by setting the meshConfig.outboundTrafficPolicy.mode | external service access will not be controlled |