Loading...

Epic Name:
netobserv-security-hardening
Blocked:
False
Blocked Reason:
None
Ready:
False
Color Status:
Not Selected
Epic Status:
To Do
Flagged:

Impediment
Hierarchy Progress Bar:

0% To Do, 0% In Progress, 100% Done
Size:
L
Status Summary:

Hide

Status currently Green.

2 remaining stories required, one might not be needed.

Need to go through security audit and that might lead to additional work.

Most important story for now is Netobserv-489.

Show
Status currently Green. 2 remaining stories required, one might not be needed. Need to go through security audit and that might lead to additional work. Most important story for now is Netobserv-489.
Target Version:

netobserv-ocp4.12

To be refined

After a first quick discussion, we identified the main lines of what to do, however many points are still to be refined. Main lines are:

More TLS (FLP, Kafka, Loki, ~~Console plugin~~, eBPF via gRPC...)
- What about OVS? To implement in OVS (UDP)? See also IPSec https://rcarrata.com/openshift/ipsec-opc4/ ; how about perf overhead?
- Is it needed for intra-node com? (OVS to FLP daemonset)
- Already done in console plugin
Minimize granted permissions / capabilities
- ~~eBPF => CAP_BPF~~ (already done)
- review current operator and workloads RBAC permissions
Data access
- Only allow cluster admins to view the data? (but what is a cluster admin?)
- Impacts on Console Plugin: use the logged in user token to check permissions
- Impacts on Loki
  - Either restrict Loki access to only FLP (ingester) and Console plugin (querier)
  - Or use the loki-operator gateway for finer access, but it needs to be modified