Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[infoblox_bloxone_ddi] Initial Release for the Infoblox BloxOne DDI #4118

Merged
merged 6 commits into from
Sep 29, 2022

Conversation

vinit-chauhan
Copy link
Contributor

@vinit-chauhan vinit-chauhan commented Sep 1, 2022

What does this PR do?

  • Generated the skeleton of the Infoblox BloxOne DDI integration package.
  • Added data streams.
  • Added data collection logic for all the data streams.
  • Added the ingest pipeline for all the data streams.
  • Mapped fields according to the ECS schema and added Fields metadata in the appropriate yml files.
  • Added dashboards and visualizations.
  • Added test for pipeline for all the data streams.
  • Added system test cases for all the data streams.

NOTE: DNS Data and DHCP Lease data streams are not tested with live data.

Integration release checklist

This checklist is intended for integrations maintainers to ensure consistency
when creating or updating a Package, Module or Dataset for an Integration.

All changes

  • Change follows the contributing guidelines
  • Supported versions of the monitoring target are documented
  • Supported operating systems are documented (if applicable)
  • Integration or System tests exist
  • Documentation exists
  • Fields follow ECS and naming conventions
  • At least a manual test with ES / Kibana / Agent has been performed.
  • Required Kibana version set to: ^7.17.0 || ^8.0.0

New Package

  • Screenshot of the "Add Integration" page on Fleet added

Dashboards changes

  • Dashboards exists
  • Screenshots added or updated
  • Datastream filters added to visualizations

Log dataset changes

  • Pipeline tests exist (if applicable)
  • Generated output for at least 1 log file exists
  • Sample event (sample_event.json) exists

How to test this PR locally

  • Clone integrations repo.
  • Install elastic package locally.
  • Start elastic stack using elastic-package.
  • Move to integrations/packages/infoblox_bloxone_ddi directory.
  • Run the following command to run tests.

elastic-package test

Related issues

Screenshots

image
image
image
image
image
image

@vinit-chauhan vinit-chauhan added enhancement New feature or request Team:Security-External Integrations New Integration Issue or pull request for creating a new integration package. labels Sep 1, 2022
@elasticmachine
Copy link

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

@vinit-chauhan vinit-chauhan changed the title Initial Release for the BloxOne DDI [bloxone_ddi] Initial Release for the BloxOne DDI Sep 1, 2022
@elasticmachine
Copy link

elasticmachine commented Sep 1, 2022

💚 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: 2022-09-22T11:36:49.701+0000

  • Duration: 16 min 29 sec

Test stats 🧪

Test Results
Failed 0
Passed 19
Skipped 0
Total 19

🤖 GitHub comments

Expand to view the GitHub comments

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

  • /test : Re-trigger the build.

@elasticmachine
Copy link

elasticmachine commented Sep 1, 2022

🌐 Coverage report

Name Metrics % (covered/total) Diff
Packages 100.0% (3/3) 💚
Files 100.0% (3/3) 💚 2.708
Classes 100.0% (3/3) 💚 2.708
Methods 100.0% (39/39) 💚 10.35
Lines 98.278% (2568/2613) 👍 6.989
Conditionals 100.0% (0/0) 💚

Comment on lines 31 to 34
- name: protocol
type: group
fields:
- name: fqdn
Copy link
Contributor

Choose a reason for hiding this comment

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

In the API this is protocol_fqdn. Is there a need to make a new level for this here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The only reason why we have kept protocol as an object is to handle new fields that are introduced in the future, we can add it directly as a child to existing protocol objects and fields do not have to be flattened. Moreover, switching from flattened to the nested field would be a breaking change for dashboards, and search queries users have already made. However, if you think this change is required, we can change it.

Copy link
Contributor

Choose a reason for hiding this comment

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

That seems reasonable. @andrewkroh?

Comment on lines 55 to 60
- name: protocol
type: group
fields:
- name: zone
type: keyword
description: Zone FQDN in punycode.
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar question here; the original is protocol_zone.

Also elsewhere.

I'm wondering in general if a more informative name might be better, these fields are always the punycode equivalent of their partner. So perhaps calling them punycode rather than protocol might be better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have kept it the same because the end user might be more familiar with the original field name ( protocol_zone ) sent by the vendor, and changing it might confuse the user.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure about this. I agree that users my be accustomed to the protocol_zone name, but that's not what we have here because of the change in name; so now we have ….zone which I think is also confusing. I don't know what should be done about this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree that the user won’t be familiar with protocol.zone. However, I believe that transition from protocol_zone to protocol.zone would be much easier, instead of the user seeing a completely different name. Let me know if you think otherwise.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's essentially the same question as above. I'm not strongly opposed to how it is right now, so let's leave it as is unless someone else feels strongly about it.

@vinit-chauhan vinit-chauhan changed the title [bloxone_ddi] Initial Release for the BloxOne DDI [infoblox_bloxone_ddi] Initial Release for the Infoblox BloxOne DDI Sep 21, 2022
@elasticmachine
Copy link

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request Integration:infoblox_bloxone_ddi Infoblox BloxOne DDI New Integration Issue or pull request for creating a new integration package.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Infoblox BloxOne DDI
4 participants