No audit events for process step changes


(Cronje van Heerden) #1

Using Octopus v2018.4.4

Scenario: I’ve created a new Octopus project, which contains a single process step using the built-in step template “Run a Script”. I defined the script as a Powershell script, with the script included in the step template.

Expected: When viewing the Octopus audit history, I’m expecting to see audit events of type, “Document modified” for adding the new process step, as well as audit event for each time that I change the body of the script defined in the step.

Getting: The audit log only displays Deploy events for this project. No Document Modified events are available, and the last document modified event overall on the installation is several days old, despite making numerous changes to the variables in the project as well as the script body of the step template. There are also no “Document Modified” audit events for adding new variables to this project, or for when the variables were modified.

Concern: It poses a massive security risk to our infrastructure arbitrary “Run a script” steps can be modified without audit logging. Even if were to to forbid the use the “Run a script” step template, there is currently no audit history available that this step has even been added to the Project configuration.

The help documentation states: Octopus does capture the details of every mutating action (create/edit/delete) including who initiated the action, which is not happening reliably in our installation.

(Tom Williams) #2

Hi Cronje,

Thanks for reaching out. Sorry to hear you have hit this issue with Octopus.
There should definitely be audit logging for those events. We do have a current open bug that prevents some users from viewing all the audit logs if that user also belong to another team that does not have permissions to view the audit logs on the project you are attempting view the logs on.
An example of this would be if your user is in the Octopus Administrators team and is also part of another team that has the EventView permission and that second team is scoped to projects not including the one you are attempting to view Audits on.

A temporary work around for this bug would be to have your user belong to a team that has the Project in question explicitly selected in the team.

I hope that helps, please reach out if you have any further questions.

Kind Regards,

(Cronje van Heerden) #3

That did it - thanks …

(David Roberts) #4

FYI, still seeing this behavior in 2018.6.2.

That workaround does do the trick though.