Closed itaysk closed 3 years ago
Can I work on this? @itaysk can you guide me a bit in resolving this? Thanks.
Hi @avats-dev , the issue I raise here is that the AzureSpnHunter only kicks in after it sees an ExposedRunHandler. ExposedRunHandler means that KH has found an open /run endpoint on the kubelet that can be used to run any pod. I don't think that ExposedRunHandler should be a prerequisite for AzureSpnHunter, because maybe my cluster doesn't have the ExposedRunHandler (which is a cluster issue) but one of my pods have the AzureSpnHunter vulnerability (which is a workload configuration issue). This is the line that I proposed to change: https://github.com/aquasecurity/kube-hunter/blob/master/kube_hunter/modules/hunting/aks.py#L28 You can work on this but first let's give @danielsagi a chance to comment as he's the original author.
Ok @itaysk , thanks for the insights.
@itaysk The original problem I had with registering to a more generic event, is that we still dont have a multiple subscribe mechanism. #271
If we were to only register to a more generic event, then in the case an active scan was initiated, we would run ProveAzureSpnExposure
with no knowledge if the /run handler is opened. and we need to register the active hunter only to AzureSpnExposure
.
Perhaps it is best if we indeed subscribe the passive hunter to ExposedPodsHandler
and just add a manual check on the active hunter for /run
As a followup to #370 I'm investigating some cases where
AzureSpnHunter
didn't work as expected. I think it should not subscribe toExposedRunHandler
but to a more generic event. I get why theProveAzureSpnExposure
should, but the vulnerability should be reported regardless. But maybe I'm missing something @danielsagi ?