Skip to main content

Hello! 

When a deployment is created in Kubernetes, it is possible to add a field as part of the securityContext named runAsUser. If the value in this field is 0, that means the deployment is run as root, which is not good at all from a security perspective. So, we would like to detect when this happens using Chronicle.

In the documentation [1], it is possible to see an entry that ends with runAsUser, so that means the parser is able to do so. Also in the code it is shown:

 

But when doing tests i.e., when deploying a deployment with the value and then chronicle consuming it and processing it, the runasUser mapped field is not displayed 😞

I open support case #55363713. After two months the issue is still present. The "solution" of the support case is "Engineering team already fixed the request as a best effort. Please, open a new case." 

Two main questions please: 

1. What to do when the documentation says one thing, and the code is in the product, but the product does not behave as expected? My guess was to open a support case, but it seems that is not the way, at least in this case.

2. Have you had this type of answer in support cases? What can be done? Is it normal to wait two months and receive that kind of answer? I I don't want to end in an endless "done-best-effort -> open-a-new-case" loop

Thank you!!!

 

[1] https://cloud.google.com/chronicle/docs/ingestion/default-parsers/collect-audit-logs

Hi and we apologize.   Support should not take that long.  They did offer a solution to this case back on 2/17.  


I would ask that you open another case and respond quickly to them.  There are large gaps of time where this case did not have any response.  


As for the parsing...


Is this coming over in the raw log?  


 


 


 


 

Hi and we apologize.   Support should not take that long.  They did offer a solution to this case back on 2/17.  


I would ask that you open another case and respond quickly to them.  There are large gaps of time where this case did not have any response.  


As for the parsing...


Is this coming over in the raw log?  


 


 


 


 


Hi, I already have another support case but I feel I wasted two months of time, both from GCP support side and my side. You can test for yourself and see that the issue still is happening, so there is still no solution. I think I always responded fast but had to wait sometimes until an answer, so that might be the reason of the gaps. 

Anyway, regarding the raw logs, I would expect the runasuser (purple line) to be between allowPrivilegeEscalation (red line in the image) and termination_message_path (yellow line in the image), but it simply is not there (it might be somewhere else and not precisely between those two, but it is not, I already search)

 BTW, I have the tech part of this case in "Parse a specific field (runasuser) from kubernetes into SecOps" post. I created two: one for the support process (this) and another for the tech part (the other.) (if you think I should only have one, we can continue on only one)

 

Hi, I already have another support case but I feel I wasted two months of time, both from GCP support side and my side. You can test for yourself and see that the issue still is happening, so there is still no solution. I think I always responded fast but had to wait sometimes until an answer, so that might be the reason of the gaps. 

Anyway, regarding the raw logs, I would expect the runasuser (purple line) to be between allowPrivilegeEscalation (red line in the image) and termination_message_path (yellow line in the image), but it simply is not there (it might be somewhere else and not precisely between those two, but it is not, I already search)

 BTW, I have the tech part of this case in "Parse a specific field (runasuser) from kubernetes into SecOps" post. I created two: one for the support process (this) and another for the tech part (the other.) (if you think I should only have one, we can continue on only one)

 


You would need to modify the parser to map those fields properly.  

You would need to modify the parser to map those fields properly.  


Is it required if it is documented and in the code? Check that in  https://cloud.google.com/chronicle/docs/ingestion/default-parsers/collect-audit-log the 

target.resource.attribute.labels[req_spec_template_spec_security_context_run_as_user] 

is documented. Also as shown in the image, the code already exists in the parser. So it seems like a bug and not something new to be implemented. Hence the case. 

Reply


Terms & ConditionsCookie settings
Privacy Policy Terms of Service Gen AI Policy Community Guidelines Cookie Settings

© 2025 Google. All rights reserved.