8 | {children}
9 |
10 | )
11 | }
12 |
13 | export function QuickLink({ title, description, href, icon }) {
14 | return (
15 |
16 |
17 |
30 | )
31 | }
32 |
--------------------------------------------------------------------------------
/docs/src/pages/docs/how-to-contribute.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: How to contribute
3 | description: How can you contribute to Netchecks?
4 | ---
5 |
6 | The Netchecks project is open source and welcomes contributions from the community. There are many ways to contribute to
7 | the project, including:
8 |
9 | - Reporting bugs
10 | - Suggesting new features
11 | - Contributing code
12 | - Contributing documentation
13 |
14 | The place to start is GitHub. If you find a bug or have a feature request, please open an issue in the appropriate
15 | repository. If you want to contribute code, please open a pull request.
16 |
17 | ## Code Repository
18 |
19 | The code is available under the [netchecks](https://github.com/hardbyte/netchecks/) Github repository.
20 |
21 | ### Docs
22 |
23 | Documentation is available in the folder [netchecks/docs](https://github.com/hardbyte/netchecks/tree/main/docs).
24 |
25 |
26 | ### Netcheck Probe
27 |
28 | The command line tool that runs the network probes is called `netcheck`. It is implemented in Python and is available
29 | as a PyPi package. The source code is available in the [netchecks](https://github.com/hardbyte/netchecks/) repository
30 | on GitHub.
31 |
32 | ### Netcheck Operator
33 |
34 | The netchecks operator is implemented in Python using the [kopf](https://kopf.readthedocs.io/en/stable) framework
35 | and is available in the [operator](https://github.com/hardbyte/netchecks/tree/main/operator) folder on GitHub.
36 |
--------------------------------------------------------------------------------
/docs/src/pages/docs/architecture-guide.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Architecture guide
3 | description: Netchecks architecture overview.
4 | ---
5 |
6 | Netchecks runs in Kubernetes as an [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/). The
7 | operator is implemented in Python using the [kopf](https://kopf.readthedocs.io/en/stable) framework.
8 |
9 | The netchecks operator:
10 | - Listens for `NetworkAssertion` resources across the kubernetes cluster and creates `CronJobs` (or `Jobs`) for each of them.
11 | - Probe pods are created by the `CronJob` and run the tests that make up a particular network assertion. External data may be mounted into the Pod for use by the probe.
12 | - Listens for _probe_ Pods created by the NetworkAssertion's CronJob and parses assertion results from the Pod logs.
13 | - Creates and updates `PolicyReport` resources for each NetworkAssertion in response to the assertion results.
14 |
15 | Each probe pod uses the `netchecks` docker image to run the tests that make up a particular network assertion.
16 |
17 |
18 | 
19 |
20 | ---
21 |
22 | The `netchecks` image is based on the [python:3.11-slim](https://hub.docker.com/_/python) image.
23 |
24 | [Kyverno's PolicyReporter](https://kyverno.github.io/policy-reporter/) is optionally installed alongside Netchecks to
25 | provide a convenient way to expose metrics, view the results, and generate notifications.
26 |
--------------------------------------------------------------------------------
/operator/examples/cilium-dns-restrictions/dns-restrictions-assertion.yaml:
--------------------------------------------------------------------------------
1 | apiVersion: netchecks.io/v1
2 | kind: NetworkAssertion
3 | metadata:
4 | name: dns-restrictions-should-work
5 | annotations:
6 | description: Check cluster dns restrictions are working
7 | spec:
8 | schedule: "*/1 * * * *"
9 | rules:
10 | - name: approved-dns-host-lookup-should-work
11 | type: dns
12 | host: github.com
13 | expected: pass
14 | validate:
15 | message: DNS requests to an approved host.
16 | - name: approved-dns-host-subdomain-lookup-should-work
17 | type: dns
18 | host: status.github.com
19 | expected: pass
20 | validate:
21 | message: DNS requests for a subdomain of an approved host.
22 | - name: k8s-svc-dns-lookup-should-work
23 | type: dns
24 | host: kubernetes.default
25 | expected: pass
26 | validate:
27 | message: DNS lookup of the kubernetes service with namespace should work.
28 | - name: k8s-svc-dns-lookup-should-work
29 | type: dns
30 | host: kubernetes.default.svc
31 | expected: pass
32 | validate:
33 | message: DNS lookup of the kubernetes service should work.
34 | - name: k8s-svc-with-cluster-domain-lookup-should-work
35 | type: dns
36 | host: kubernetes.default.svc.cluster.local
37 | expected: pass
38 | validate:
39 | message: DNS lookup of the kubernetes service should work.
40 |
--------------------------------------------------------------------------------
/docs/src/pages/docs/writing-plugins.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Writing plugins
3 | description: How to write a plugin for Netchecks
4 | ---
5 |
6 |
7 | {% callout type="warning" title="Not Implemented Yet" %}
8 |
9 | The plugin architecture is still under design. Please get in touch if you'd like to help.
10 |
11 | {% /callout %}
12 |
13 | ## Plugin goals
14 |
15 | Netchecks will provide a plugin framework that allows:
16 |
17 | - extending the set of network assertions with new types of checks.
18 |
19 |
20 | Currently, the Netcheck probe command line tool is written in Python. The plugin framework will allow writing
21 | assertions in other languages such as Rust, Go, or C.
22 |
23 | There are a couple of options for installing plugins in the Netcheck probe. The first is to install the
24 | plugin as a Python package in the main distributed container before running any assertions - although this
25 | assumes the Python package (e.g. on PyPi) can be reached. The second is to install the plugin in a separate
26 | Docker image.
27 |
28 | Likely users will be able to build their own Docker images that build upon the Netcheck probe
29 | base image adding plugins for custom assertions.
30 |
31 | The operator needs to be know to use the appropriate Docker image - this could be done by:
32 | - configuring the default probe image for all NetworkAssertions during operator installation, or
33 | - configuring the probe image for each NetworkAssertion individually.
34 |
35 |
--------------------------------------------------------------------------------
/docs/src/components/Prose.jsx:
--------------------------------------------------------------------------------
1 | import clsx from 'clsx'
2 |
3 | export function Prose({ as: Component = 'div', className, ...props }) {
4 | return (
5 |
18 |
29 | 20 | 21 | 22 | {title} 23 | 24 |
25 |26 | {description} 27 |
28 |
38 |
48 | )
49 | }
50 |
--------------------------------------------------------------------------------
/operator/examples/cilium-cluster-wide-dns-restrictions/dns-restrictions-assertion.yaml:
--------------------------------------------------------------------------------
1 | apiVersion: netchecks.io/v1
2 | kind: NetworkAssertion
3 | metadata:
4 | name: dns-restrictions-should-work
5 | namespace: default
6 | annotations:
7 | description: Check cluster dns restrictions are working
8 | spec:
9 | # Every 20 minutes
10 | schedule: "*/1 * * * *"
11 | rules:
12 | - name: external-dns-lookup-should-fail
13 | type: dns
14 | server: 1.1.1.1
15 | host: hardbyte.nz
16 | expected: fail
17 | validate:
18 | message: DNS requests using an external DNS provider such as cloudflare should fail.
19 | - name: external-dns-host-lookup-should-fail
20 | type: dns
21 | host: hardbyte.nz
22 | expected: fail
23 | validate:
24 | message: DNS requests to a non-approved host should fail.
25 | - name: approved-dns-host-lookup-should-work
26 | type: dns
27 | host: github.com
28 | expected: pass
29 | validate:
30 | message: DNS requests to an approved host.
31 | - name: approved-dns-host-subdomain-lookup-should-work
32 | type: dns
33 | host: status.github.com
34 | expected: pass
35 | validate:
36 | message: DNS requests for a subdomain of an approved host.
37 | - name: internal-k8s-service-dns-lookup-should-work
38 | type: dns
39 | host: kubernetes
40 | expected: pass
41 | validate:
42 | message: DNS lookup of the kubernetes service should work.
43 | - name: k8s-svc-dns-lookup-should-work
44 | type: dns
45 | host: kubernetes.default
46 | expected: pass
47 | validate:
48 | message: DNS lookup of the kubernetes service with namespace should work.
49 | - name: k8s-svc-dns-lookup-should-work
50 | type: dns
51 | host: kubernetes.default.svc
52 | expected: pass
53 | validate:
54 | message: DNS lookup of the kubernetes service should work.
55 | - name: k8s-svc-with-cluster-domain-lookup-should-work
56 | type: dns
57 | host: kubernetes.default.svc.cluster.local
58 | expected: pass
59 | validate:
60 | message: DNS lookup of the kubernetes service should work.
61 |
--------------------------------------------------------------------------------
/docs/src/pages/docs/core-concepts.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Core Concepts
3 | description: Core concepts for Netchecks
4 | ---
5 |
6 | ## Continuous Assurance
7 |
8 | Continuous Assurance is a proactive approach to ensure network policies, connectivity, and security within a Kubernetes cluster are continuously monitored and verified. By leveraging the Netchecks operator and its NetworkAssertions, users can schedule automated network tests at regular intervals. This ongoing validation process helps maintain a high level of network reliability, security, and compliance, providing peace of mind and reducing the risk of unexpected network issues.
9 |
10 | ## Alerting
11 |
12 | Alerting is a crucial aspect of maintaining a reliable and secure Kubernetes environment. With Netchecks and the Kyverno Policy Reporter, you can set up alerting based on the results of your NetworkAssertions and the generated PolicyReports. This enables you to get notified about potential network issues, policy violations, or other anomalies, ensuring timely response and remediation.
13 |
14 |
15 | ## Network Assertions
16 |
17 |
18 | Network Assertions are the core building blocks for defining and managing network tests within the Netchecks framework.
19 |
20 | They allow users to create custom rules that specify the expected behavior of various network-related components, such as DNS resolution or HTTP requests.
21 |
22 | Network Assertions are written in YAML format and can be applied like any other Kubernetes resource.
23 |
24 | They support various check types and can include custom validation rules using the CEL (Common Expression Language) to tailor the assertion criteria to specific use cases.
25 |
26 | ### Custom Validation
27 |
28 | Netchecks provides built-in default validation for each check type, such as ensuring a DNS response code is NOERROR and contains at least one A record. However, users may need to implement custom validation rules for more specific requirements. Netchecks allows users to write custom validation rules using the CEL (Common Expression Language), offering a flexible and powerful way to extend the default validation logic. Custom validation rules can be added to Network Assertions or used in command-line checks to ensure the network behaves as expected under various conditions.
29 |
30 |
31 |
--------------------------------------------------------------------------------
/docs/src/components/Icon.jsx:
--------------------------------------------------------------------------------
1 | import { useId } from 'react'
2 | import clsx from 'clsx'
3 |
4 | import { InstallationIcon } from '@/components/icons/InstallationIcon'
5 | import { LightbulbIcon } from '@/components/icons/LightbulbIcon'
6 | import { PluginsIcon } from '@/components/icons/PluginsIcon'
7 | import { PresetsIcon } from '@/components/icons/PresetsIcon'
8 | import { ThemingIcon } from '@/components/icons/ThemingIcon'
9 | import { WarningIcon } from '@/components/icons/WarningIcon'
10 |
11 | const icons = {
12 | installation: InstallationIcon,
13 | presets: PresetsIcon,
14 | plugins: PluginsIcon,
15 | theming: ThemingIcon,
16 | lightbulb: LightbulbIcon,
17 | warning: WarningIcon,
18 | }
19 |
20 | const iconStyles = {
21 | blue: '[--icon-foreground:theme(colors.slate.900)] [--icon-background:theme(colors.white)]',
22 | amber:
23 | '[--icon-foreground:theme(colors.amber.900)] [--icon-background:theme(colors.amber.100)]',
24 | }
25 |
26 | export function Icon({ color = 'blue', icon, className, ...props }) {
27 | let id = useId()
28 | let IconComponent = icons[icon]
29 |
30 | return (
31 |
40 | )
41 | }
42 |
43 | const gradients = {
44 | blue: [
45 | { stopColor: '#0EA5E9' },
46 | { stopColor: '#22D3EE', offset: '.527' },
47 | { stopColor: '#818CF8', offset: 1 },
48 | ],
49 | amber: [
50 | { stopColor: '#FDE68A', offset: '.08' },
51 | { stopColor: '#F59E0B', offset: '.837' },
52 | ],
53 | }
54 |
55 | export function Gradient({ color = 'blue', ...props }) {
56 | return (
57 |
40 |
47 | 41 | {title} 42 |
43 |
44 | {children}
45 |
46 |
34 |
35 | {copied ?
52 | )}
53 |
38 |
39 | {tokens.map((line, lineIndex) => (
40 |
41 | {line
42 | .filter((token) => !token.empty)
43 | .map((token, tokenIndex) => (
44 |
45 | ))}
46 | {'\n'}
47 |
48 | ))}
49 |
50 |
51 |