Create ADR for exposing TLS endpoints and required SecretClass/AuthenticationClass via discovery ConfigMaps
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- kafka
- Domain
- documentation, security
Research direction
No files or tests are named. Start by reviewing the existing discovery ConfigMaps and the three ZooKeeper fields listed in the issue, then define the product-independent conventions the ADR must cover. Done means a discussed, documented ADR in valid YAML or JSON describing secure endpoints and required SecretClass or AuthenticationClass fields.
Written by the indexing model from the issue text.
Description
We enable more and more operators to use TLS for their products. We have dependencies between operators via discovery (e.g. Kafka -> ZooKeeper) where we currently expose a connection string (adapted to the secure port etc.), but we do not expose what secret class or authentication class must be used if authentication is required. After, a quick discussion with Sönke we agreed that we need to expose the secret or authentication class (e.g. the one used for client TLS in ZooKeeper) in the discovery ConfigMap.
For ZooKeeper we currently expose 3 fields:
- ZOOKEEPER contains the full zookeeper connection string with znode (generally used)
- ZOOKEEPER_CHROOT contains the znode (i think only for Nifi currently)
- ZOOKEEPER_HOSTS contains the zookeeper connection string without znode (i think only for Nifi currently)
I think we should (if set) in similar fashion secure fields like:
- ZOOKEEPER_SECURE
- ZOOKEEPER_HOSTS_SECURE
- (ZOOKEEPER_CHROOT_SECURE) would be redundant
- AUTHENTICATION_CLASS
to be able to connect products to e.g. ZooKeeper.
This should be properly discussed and documented in an new ADR, provided in machine readable format (yaml, json) and valid for different products.
- Dominant language
- CSS
- Stars
- 13
- Forks
- 14
- Avg merge
- 4d 8h
- Merged PRs (30d)
- 10
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stackabletech/documentation
-
Withdraw ADR018 Open
Difficulty 1/5 Under an hour Newbie friendliness 68/100
stackabletech/documentation#734 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
stackabletech/documentation#779 ·
-
customer-request
Difficulty 4/5 3-5 days Newbie friendliness 35/100
stackabletech/documentation#773 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
stackabletech/documentation#754 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
stackabletech/documentation#753 ·
All issues in stackabletech/documentation
Similar issues
-
Add: hunch Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AbdelStark/awesome-typesafe#104 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
A11y ♿️
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Link Checker Report Openautomated issue report
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
documentation improve or update documentation priority/low triage
Difficulty 2/5 Half a day Newbie friendliness 86/100
warpdotdev/docs#782 · 1 comment ·