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

Access Audit Log #179

Closed
joshuakarp opened this issue Jun 2, 2021 · 8 comments
Closed

Access Audit Log #179

joshuakarp opened this issue Jun 2, 2021 · 8 comments
Assignees
Labels
enhancement New feature or request r&d:polykey:core activity 1 Secret Vault Sharing and Secret History Management

Comments

@joshuakarp
Copy link
Contributor

Created by @CMCDragonkai

Any access to secret vaults should be logged, and maybe we can use the atime of files/directories. I dont remember how directory atimes are updated.

It can show who/what/when/how.

Access logs can go into a file, or go to stderr.

  • Going to stderr allows users to integrate external audit logging systems.
  • Going to file means pk will then show the logs over time.

It also means logging format should be structured. There is a syslog standard but... opentracing might an interesting idea here.

This is just for research now, not part of MVP.


These were the dependencies for opentelemetry:

    "@opentelemetry/exporter-jaeger": "^0.12.0",
    "@opentelemetry/exporter-prometheus": "^0.12.0",
    "@opentelemetry/metrics": "^0.12.0",
    "@opentelemetry/node": "^0.12.0",
    "@opentelemetry/tracing": "^0.12.0",

Can tracing be used for user analytics? I'd rather not have too much dependencies brought in to do such small part of polykey.

@CMCDragonkai
Copy link
Member

Our experiment with open telemetry showed that it was too heavyweight to use for an application like Polykey. It's far more used for server side applications.

Since we now have the sigchain, this is something that can be applied to the sigchain instead, but we still have to spec out how this feature would work, and what kind of claim types can be announced on the sigchain, and how this would work into data-provenance or secret-provenance flow.

@CMCDragonkai
Copy link
Member

Audit logging will be tied up with organisation secret sharing policies.

@CMCDragonkai CMCDragonkai added the r&d:polykey:core activity 1 Secret Vault Sharing and Secret History Management label Jul 24, 2022
@CMCDragonkai
Copy link
Member

Audit log is a key feature of PKE. This is going into PKE. However there will need to be a place for PK to keep the logs first. Since audit log data can be sensitive, we might just need to keep it in the database. And this not like debugging logs, these logs have meaning. So they need to be fairly high level. For local logging we will want to maintain a log-count that basically discards older logs once we hit the count, or a log expiry which is based on time. This is to prevent PK nodes from just building up loads and loads of logs. However this information can then be sent to PKE, which can in fact save all the logs forever due to utility-pricing, up to the limit specified by the user.

@tegefaulkes
Copy link
Contributor

We could use the audit domain for this. Although I want to avoid new features at this stage. Polish and fixes for now.

@CMCDragonkai
Copy link
Member

Yes these are for high level audits. But the same audit domain.

@CMCDragonkai
Copy link
Member

This needs to be re-specced into a high level issue.

Copy link
Member

I would open a new issue to re-spec this issue, and close it off as cancelled like I'm doing with the high level projects.

@CMCDragonkai
Copy link
Member

This is closed in favour of #628. So this issue was forgotten about. The OP spec is no longer relevant as telemetry data would be more suitable to diagnostics or operational behaviour.

@CMCDragonkai CMCDragonkai closed this as not planned Won't fix, can't repro, duplicate, stale May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request r&d:polykey:core activity 1 Secret Vault Sharing and Secret History Management
Development

No branches or pull requests

4 participants