initial commit of new dmarc2logstash chart

[jertel]

What this PR does / why we need it:
This PR adds a new chart to the stable repository. The chart will deploy an application called dmarc2logstash. This app polls a POP3 account for DMARC aggregated reports, unpacks them, converts them into JSON, and uses filebeat to forward them into Logstash. The purpose of the application is to provide all of the standardized RFC 7489 DMARC summary data into Elasticsearch so that email administrators have an easier job at locating problems with DKIM and SPF email/domain settings. This will reduce the level of effort to troubleshoot email messages not reaching their intended recipients due to various problems, such as messages landing in spam folders, being rejected from MTAs, etc.

A quick review of available, similar solutions resulted in none that were Docker-friendly and Helm-compatible, this PR aims to close that gap.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Not applicable as this is a new chart.

Special notes for your reviewer:
The dmarc2logstash application is open-sourced at https://github.com/jertel/dmarc2logstash, along with the Dockerfile which auto-builds into https://hub.docker.com/r/jertel/dmarc2logstash/.

[jertel]

/assign @prydonius

[unguiculus]

Thanks for the PR. The is a separate chart for Filebeat (https://github.com/kubernetes/charts/tree/master/stable/filebeat). Could you use that as a dependency instead?

[unguiculus]

Use fullname template for the name and add standard labels.

[unguiculus]

Use fullname template for name.

[unguiculus]

app: {{ template "dmarc2logstash.name" . }}

[unguiculus]

/assign

[jertel]

Thanks for the quick feedback. I've implemented the chart changes, except for the filebeat requirements.yaml suggestion. I don't think I can use the existing filebeat chart for two reasons:

1. The filebeat in this dmarc2logstash project is a running as sidecar container, not as a separate pod.
2. The filebeat chart you referenced is intended to collect arbitrary Kubernetes and Docker engine logs, such as those generated from pods sending console output to STDOUT, for injection into an Elastic stack, whereas dmarc2logstash is using filebeat in a specific way -- it uses filebeat to take a specific JSON file residing within the pod itself.

[timstoop]

Argument makes sense and it generally looks good to me. However, I'm hesitant to allow it to test, as I expect it will fail on the POP3 requirement. We'll need to figure out a way to make a default installation work without crashing, without having a POP3 server available?

[jertel]

Yes, these charts with dependencies upon external running services are problematic when it comes to the automated tests. I've worked around this on this chart as well as another PR by preventing the deployment from being installed if a host config value isn't supplied (see line 1 of https://github.com/jertel/charts/blob/dmarc2logstash-initial/stable/dmarc2logstash/templates/deployment.yaml), which by default it is set to an empty string. When the test runs it will install the config map but not the deployment itself. The NOTES.txt explains why the deployment wasn't installed so for an actual chart user it should be clear that they need to specify some required inputs. It's a workaround but gets us past the issue for now.

[timstoop]

So I understand the reasons for doing so, but I don't feel it's the right solution for a Chart in stable. However, I do not have a solution either. I'm going to leave this to the veterans and see (and learn) from how they'll propose to solve this. But it's a dilemma, for certain.

[unguiculus]

@timstoop There's no other way than to install things conditionally.

@jertel We tend to go with extraConainers, extraSecrets, extraVars, etc. Would you mind updating the PR to follow this pattern?

[timstoop]

/ok-to-test
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jertel, timstoop
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: prydonius

Assign the PR to them by writing /assign @prydonius in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please email the CNCF helpdesk: helpdesk@rt.linuxfoundation.org

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.