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

Add datastream to collect audit logs in kubernetes integration #2317

Merged

Conversation

tetianakravchenko
Copy link
Contributor

Signed-off-by: Tetiana Kravchenko tetiana.kravchenko@elastic.co

What does this PR do?

This PR adds a new data stream in kubernetes integration to collect audit logs.

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

How to test this PR locally

cd  package/kubernetes
elastic-package build
elastic-package stack up -d -v --version 8.1.0-f479a40a-SNAPSHOT
  1. Start kind with auditing enabled, as described here:
kind create cluster --config kind-config.yaml
  1. connect networks:
docker network connect elastic-package-stack_default kind-control-plane
  1. deploy elastic-agent:
kubectl apply -f elastic-agent-managed-kubernetes.yaml

Related issues

Screenshots

Screenshot 2021-12-06 at 14 30 53

Screenshot 2021-12-06 at 15 48 24

Screenshot 2021-12-06 at 15 49 02

Screenshot 2021-12-06 at 15 55 27

@elasticmachine
Copy link

elasticmachine commented Dec 6, 2021

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2021-12-15T11:20:17.386+0000

  • Duration: 29 min 15 sec

  • Commit: dca4219

Test stats 🧪

Test Results
Failed 0
Passed 115
Skipped 0
Total 115

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great addition!

  1. Could we also add sample logs along with a pipeline test?
  2. Also since I guess there is a specific pattern in these logs, will we be explicit in the fields we are storing here?

@@ -1,4 +1,9 @@
# newer versions go on top
- version: "1.5.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- version: "1.5.1"
- version: "1.6.0"

New feature ;)

@tetianakravchenko
Copy link
Contributor Author

@ChrsMark thank you for the feedback!

  1. Could we also add sample logs along with a pipeline test?

I will have a look how to add it 👍

  1. Also since I guess there is a specific pattern in these logs, will we be explicit in the fields we are storing here?

do you mean specifically kubernetes.audit.*?

@ChrsMark
Copy link
Member

ChrsMark commented Dec 6, 2021

  1. Also since I guess there is a specific pattern in these logs, will we be explicit in the fields we are storing here?

do you mean specifically kubernetes.audit.*?

Well if the possible fields are unknown then yes we can do something similar to what we do for kubernetes.labels.* or prometheus.labels.*. Otherwise if the fields are specific we can define them like kubernetes.audit.verb etc. Maybe https://kubernetes.io/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event can be of help here?

@@ -0,0 +1,15 @@
title: "Kubernetes audit logs"
type: logs
release: experimental
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ChrsMark should I keep it as experimental ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be experimental or beta at least until we have tests+dashboards. @akshay-saraswat could confirm this too.

parsers:
- ndjson:
add_error_key: true
target: "kubernetes_audit"
Copy link
Contributor Author

@tetianakravchenko tetianakravchenko Dec 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without defined target - decoded json fields will be written under root
related issue - elastic/beats#29422

- rename:
fields:
- from: "kubernetes_audit"
to: "kubernetes.audit"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is not possible to use kubernetes.audit as a target, related issue: elastic/beats#29395

function process(event) {
var audit = event.Get("kubernetes.audit");
var annotation;
for (annotation in audit["annotations"]) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove declaration of annotation and change the iteration to this

for (var annotation in audit["annotations"]) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done 6dad8d7

@ChrsMark ChrsMark self-requested a review December 14, 2021 16:39
Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I left a few thoughts about the fields.

The way that we use the parser and the script processor is the best way possible at the moment I think so we are good here, good job!

Fyi we will need dashboard and tests for this at some point. Maybe a meta issue to keep track of this would help since it's not that much urgent to have them really soon :).

description: Time the request reached current audit stage
- name: annotations.*
type: object
object_type: text
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for not using keyword here? In kubernetes it is defined as keyword: https://github.com/elastic/integrations/blob/master/packages/kubernetes/data_stream/container/fields/base-fields.yml#L57. In general we should use keyword when we want to make this field to be heavily searchable.

Also do you think we could move this field under kubernetes.annotations.* that is already defined for kubernetes? In this way we might be able to corelate events with resources, however I'm not quite sure what values these annotations of the events could take and if related with the annotations of a resource. Let me know what you think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason for not using keyword here? In kubernetes it is defined as keyword: https://github.com/elastic/integrations/blob/master/packages/kubernetes/data_stream/container/fields/base-fields.yml#L57. In general we should use keyword when we want to make this field to be heavily searchable.

I used text, because one of the fields authorization_k8s_io/reason seems to be rather an text according to the name and the example value below:

"annotations": {
      "authorization_k8s_io/decision": "allow",
       "authorization_k8s_io/reason": "RBAC: allowed by ClusterRoleBinding \"system:public-info-viewer\" of ClusterRole \"system:public-info-viewer\" to Group \"system:unauthenticated\""
            },

Do you think it would be better to use keyword instead

Also do you think we could move this field under kubernetes.annotations.* that is already defined for kubernetes? In this way we might be able to corelate events with resources, however I'm not quite sure what values these annotations of the events could take and if related with the annotations of a resource. Let me know what you think.

I think those annotations.* are not related to the resource: from the doc:

Note that these annotations are for the audit event, and do not correspond to the metadata.annotations of the submitted object. Keys should uniquely identify the informing component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values should be short. Annotations are included in the Metadata level.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I think we can leave them as is for now. In any case this is still beta so we will have the chance to iterate on this later if we have feedback.

"version": "8.0.0"
},
"host": {
"architecture": "x86_64",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For shake of simplicity we usually remove hosts's informations from sample events. A very baseline event with the actually interesting fields populated should be enough.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for letting me know, I think I've checked few sample_event files in kubernetes package (node, pod) and they actually contain all fields, including host, so the idea is just to keep kubernetes.* here, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that yes, the simple the better. I don't see any reason into having all these extra metadata for sample events that want to just show k8s relevant fields. Other data_streams might have been ported automatically and hence this is why they brought sample events from Beats repo that might container all those. I don't think it is documented somewhere however it's rather a "best-practice" convention :).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done 74b92dc

@tetianakravchenko
Copy link
Contributor Author

Fyi we will need dashboard and tests for this at some point. Maybe a meta issue to keep track of this would help since it's not that much urgent to have them really soon :).

@ChrsMark follow up ticket for tests and dashboards: #2343

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
…ssor; add script processor to dedoc annotations

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢 it!

@tetianakravchenko tetianakravchenko merged commit b45809a into elastic:master Dec 15, 2021
@tetianakravchenko tetianakravchenko deleted the audit-log-datastream branch December 15, 2021 13:14
eyalkraft pushed a commit to build-security/integrations that referenced this pull request Mar 30, 2022
…ic#2317)

* add kubernetes audit logs

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* fix pr number; commit manifest changes

* add empty line in the end; remove data_stream.namespace; fix readme

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* add sample_event; use json parser instead of decode_json_fields processor; add script processor to dedoc annotations

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* fix formatting error

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* remove declaration of annotation

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* keep only kubernetes.* fields in sample_event

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* remove only  from sample_event

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* add new sample_event

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* keep only one ip and mac

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>

* run es-package format

Signed-off-by: Tetiana Kravchenko <tetiana.kravchenko@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add audit logs datastream in K8s integration
4 participants