• netobserv-security-hardening
    • False
    • None
    • False
    • Not Selected
    • To Do
    • Impediment
    • 0% To Do, 0% In Progress, 100% Done
    • L
    • 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.
    • Approved

      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

       

            ocazade@redhat.com Olivier Cazade
            jtakvori Joel Takvorian
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: