Skip to content

Commit a4d160c

Browse files
sbernauersbernauer
committed
WIP
1 parent 5a1c80d commit a4d160c

File tree

1 file changed

+139
-9
lines changed

1 file changed

+139
-9
lines changed

‎modules/contributor/pages/adr/ADR028-discovery-revision.adoc

Lines changed: 139 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,110 @@ We have some common use-cases that we need to express via the discovery mechanis
5454

5555
== Considered Options
5656

57-
=== TLS: Discovery config contains SecretClass
57+
=== [1] Discovery Object: Use ConfigMap
58+
59+
Use a ConfigMap:
60+
61+
[source,yaml]
62+
----
63+
apiVersion: v1
64+
kind: ConfigMap
65+
metadata:
66+
name: simple-hdfs
67+
spec:
68+
data:
69+
hdfs-site.xml:
70+
core-site.xml:
71+
ca.crt: | # Containing a PEM certificate
72+
=== BEGIN CERTIFICATE ===
73+
XXX
74+
=== END CERTIFICATE ===
75+
authentication: |
76+
kerberos:
77+
secretClass: client-tls # Use this SecretClass to obtain a keytab
78+
# Alternative solution without yaml enum:
79+
authenticationType: Kerberos
80+
authenticationSecretClass: client-kerberos
81+
----
82+
83+
==== Pros
84+
85+
* Easier to use for consuming applications outside of Stackable, as they can simply mount the CM or download it to a file.
86+
On the other hand when we start to put in yaml objects that need to be parsed we would loose the benefit.
87+
88+
==== Cons
89+
90+
* No complex structure such as enums (we can mitigate this by sticking in custom yaml into the CM).
91+
Users don't have any form of validation when creating their own discovery CM e.g. pointing to their existing HDFS.
92+
93+
=== [1] Discovery Object: Use dedicated CRD object for every product
94+
95+
Or use a dedicated HdfsClusterDiscovery crd:
96+
97+
[source,yaml]
98+
----
99+
apiVersion: hdfs.stackable.tech/v1alpha1
100+
kind: HdfsClusterDiscovery
101+
metadata:
102+
name: simple-hdfs
103+
spec:
104+
hdfs-site.xml: # xml
105+
core-site.xml: # xml
106+
httpProtocol:
107+
http: {}
108+
# OR
109+
https:
110+
caBundle: | # Containing a PEM certificate
111+
=== BEGIN CERTIFICATE ===
112+
XXX
113+
=== END CERTIFICATE ===
114+
authentication: |
115+
kerberos:
116+
secretClass: client-tls # Use this SecretClass to obtain a keytab
117+
----
118+
119+
==== Pros
120+
121+
==== Cons
122+
123+
* Operator A needs to compile against operator b to have access to it's discovery struct. An alternative would be to put the Discovery CRDs in operator-rs.
124+
* Operator versioning hell. On the other hand we have the same problem with ConfigMaps, as e.g. a newly introduced key is missing because of an older hdfs operator version.
125+
126+
=== [1] Discovery Object: Use dedicated CRD object shared between all products
127+
128+
Or use a dedicated ClusterDiscovery crd:
129+
130+
[source,yaml]
131+
----
132+
apiVersion: discovery.stackable.tech/v1alpha1
133+
kind: ClusterDiscovery
134+
metadata:
135+
name: simple-hdfs
136+
spec:
137+
# Whatever
138+
----
139+
140+
==== Pros
141+
142+
* Only one struct in operator-rs -> No cross-operator dependencies.
143+
144+
==== Cons
145+
146+
* It does not seem like it's possible to find a common struct all products can agree upon
147+
148+
=== [1] Discovery Object: Write the discovery to Product CR status
149+
150+
Instead of writing discovery information to dedicated objects - such as CM or custom CR - we "simply" write the discovery information to the status of the Cluster CR.
151+
152+
==== Pros
153+
154+
==== Cons
155+
156+
* It does not enable users to bring their own product and talk to it from Stackable, e.g. a user-provided HDFS.
157+
* It does not allow things such as a ZNode for Zookeeper as we either use the Zookeeper CR for discovery or we use a ZNode but than can't use a Zookeeper CR.
158+
Currently we have the freedom of either connection to a Zookeeper root dir or a ZNode transparently.
159+
160+
=== [2] TLS: Discovery config contains SecretClass
58161
The discovery includes the SecretClass used to obtain the *server* certificate
59162

60163
Trino discovery:
@@ -87,7 +190,7 @@ backends: # Don't look at the Superset CRD structure, we are only interested in
87190

88191
==== Cons
89192

90-
=== TLS: Client needs to specify SecretClass
193+
=== [2] TLS: Client needs to specify SecretClass
91194
---
92195
The discovery does *not* include the SecretClass used to obtain the *server* certificate.
93196
Instead the client must specify which SecretClass should be used to verify the *server* certificate.
@@ -123,7 +226,7 @@ backends: # Don't look at the Superset CRD structure, we are only interested in
123226

124227
* The client has to know what pki/secretClass the server is using.
125228

126-
=== TLS: Include caCert in Discovery config
229+
=== [2] TLS: Include caCert in Discovery config
127230

128231
Trino discovery:
129232
[source,yaml]
@@ -155,7 +258,7 @@ endpoint:
155258
** The secret-op could e.g. offer an HTTP api to fetch the ca.crt of a given SecretClass or e.g. write the ca.crt into the status of a SecretClass
156259

157260

158-
=== Authentication: Add AuthenticationClass to Discovery Config
261+
=== [3] Authentication: Add AuthenticationClass to Discovery Config
159262

160263
Trino discovery:
161264
[source,yaml]
@@ -172,7 +275,7 @@ authentication:
172275
* The AuthenticationClass is meant to describe "how should a server verify connecting clients" and re-purpose it to mean "how a client should authenticate itself".
173276

174277

175-
=== Authentication: Add SecretClass to Discovery Config
278+
=== [3] Authentication: Add SecretClass to Discovery Config
176279

177280
Trino discovery:
178281
[source,yaml]
@@ -188,7 +291,7 @@ authentication:
188291
* Operator has to read the SecretClass to determine its type (pw/tls/keytab) and set up the needed volumes and commands.
189292

190293

191-
=== Authentication: Add needed details
294+
=== [3] Authentication: Add needed details
192295

193296
Trino discovery:
194297
[source,yaml]
@@ -201,15 +304,42 @@ authentication:
201304
tls:
202305
secretClass: client-tls # Use this SecretClass to obtain a *client* cert
203306
kerberos:
204-
secretClass: client-tls # Use this SecretClass to obtain a keytab
307+
secretClass: client-kerberos # Use this SecretClass to obtain a keytab
205308
oauth:
206-
secretClass: client-tls # Use this SecretClass to obtain whatever it needs
309+
secretClass: client-oauth # Use this SecretClass to obtain whatever it needs
207310
----
208311

209312
==== Pros
210313

211314
* Operator has *not* to read the SecretClass to determine its type (pw/tls/keytab), as the type is already encoded in the Discovery config.
212315

316+
==== Cons
317+
318+
* Operator has read the Discovery CM it wants to connect to
319+
213320
== Decision Outcome
214321

215-
TODO
322+
[1] Discovery Object: TODO
323+
[2] TLS: TODO
324+
[3] Authentication: TODO
325+
326+
=== Appendix A
327+
Let's model a kerberos secured HDFS with the Options "TLS: Include caCert in Discovery config" and "Authentication: Add needed details"
328+
329+
[source,yaml]
330+
----
331+
apiVersion: hdfs.stackable.tech/v1alpha1
332+
kind: HdfsCluster
333+
metadata:
334+
name: simple-hdfs
335+
spec:
336+
zookeeperConfigMapName: simple-hdfs-znode
337+
nameNodes: {}
338+
dataNodes: {}
339+
journalNodes: {}
340+
# TODO Refine CRD
341+
kerberos:
342+
tlsSecretClass: tls
343+
kerberosSecretClass: kerberos
344+
wireEncryption: Privacy
345+
----

0 commit comments

Comments
 (0)