Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial exposure analysis #293

Closed
wants to merge 1 commit into from
Closed

Conversation

shireenf-ibm
Copy link
Contributor

@shireenf-ibm shireenf-ibm commented Jan 8, 2024

No description provided.

@shireenf-ibm
Copy link
Contributor Author

hi @adisos,
this is an initial commit on exposure analysis.

  1. still didn't append the results of exposure analysis into the connlist's result
    but print them (for debug) to os.Stdout
    (and so some command tests fail as the command-line tests compare the output with os.Stdout )

  2. for now exposure analysis results contain :

  • pods which are not protected in the cluster
  • pods which are not protected for one direction Ingress/Egress)
  • pods which are captured by policies and exposed to potential namespaces (any namespace/ namespaces with particular labels)
  1. I wrote all the new functions in new files (each file in the relevant package)

  2. would like to discuss with you if changes in functionality are needed and the next steps (some were added in the issue)

  • some output examples :

Screenshot 2024-01-08 182639

Screenshot 2024-01-08 182711

Screenshot 2024-01-08 182424

Screenshot 2024-01-08 182535

@shireenf-ibm shireenf-ibm marked this pull request as draft January 8, 2024 16:50
@adisos
Copy link
Collaborator

adisos commented Jan 9, 2024

Hi @shireenf-ibm , few things to consider about the implementation:

  • can the analysis be made while iterating pods and policies for connectivity analysis, instead of adding a separate analysis only after the connectivity analysis is already done?
  • another approach to consider: can we save some code by adding fake pods, representing "arbitrary namespace" and certain namespaces appearing in policies that do not have actual resources? if an actual pod in the connectivity analysis is connected to such "fake pod" , it means that it is exposed to its representing entity (any namespace / certain namespace) ? (thus we may get "exposure results" using the "connectivity analysis" functionality instead of adding a separate analysis).
  • let's also consider how this would be extended for pods exposure analysis, without implementing yet.

@shireenf-ibm shireenf-ibm deleted the exposure_analysis_first_br branch January 13, 2024 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants