From e07675b680bbc5a9cd149bc2fb38c325e81df102 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6nke=20Liebau?= Date: Wed, 26 Aug 2020 17:31:25 +0200 Subject: [PATCH 1/4] Added draft ADRs for the following decisions (still to be taken): - agent programming language - authorization engine - orchestrator storage backend - reuse of operators --- ...DRx-choose_agent_programming_language.adoc | 84 +++++++++++++++ .../ADRx-choose_authorization_engine.adoc | 102 ++++++++++++++++++ ...x-choose_orchestrator_storage_backend.adoc | 84 +++++++++++++++ .../ADRx-decide_reuse_of_operators.adoc | 70 ++++++++++++ 4 files changed, 340 insertions(+) create mode 100644 adr/drafts/ADRx-choose_agent_programming_language.adoc create mode 100644 adr/drafts/ADRx-choose_authorization_engine.adoc create mode 100644 adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc create mode 100644 adr/drafts/ADRx-decide_reuse_of_operators.adoc diff --git a/adr/drafts/ADRx-choose_agent_programming_language.adoc b/adr/drafts/ADRx-choose_agent_programming_language.adoc new file mode 100644 index 000000000..b5f82e4c0 --- /dev/null +++ b/adr/drafts/ADRx-choose_agent_programming_language.adoc @@ -0,0 +1,84 @@ += Use xxx as programming language for the agent +Sönke Liebau +v1.0, 19.08.2020 +:status: draft + +* Status: {status} +* Deciders: +** Florian Waibel +** Lars Francke +** Lukas Menzel +** Bernd Fondermann +** Oliver Hessel +** Sönke Liebau +* Date: + +Technical Story: https://hosting-jira.1and1.org/browse/DFBAICC-520 + +== Context and Problem Statement + +Which programming language should be used in the implementation of the agent that will manage tool installations on servers? + +== Decision Drivers + +* The ability to deploy the agent as one binary with no external dependencies +* Availability of well supported libraries for necessary operations +** File IO +** Network IO +** RPC depends on link:./ADRx-Protocol-to-use-for-communication-between-agent-and-orchestrator.html[ADRx-Protocol to use for communication between agent and orchestrator] +** SystemD +* IDE support +* Debugging options + +== Considered Options + +* Java +* Go +* Rust + +== Decision Outcome + +Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. + +=== Positive Consequences + +* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] +* … + +=== Negative Consequences + +* [e.g., compromising quality attribute, follow-up decisions required, …] +* … + +== Pros and Cons of the Options + +=== Java + +* Good, because easy to find developers +* Good, because team is very familiar with it +* Bad, because it needs a jvm as dependency and is not deployable as single binary +** GraalVM has many drawbacks and licensing doubts as it is an Oracle product + +=== Go + +* Good, because it compiles to a single binary on many platforms +* Good, because Kubernetes also uses it +* Good, because there is proper IDE support with debugging +* Bad, because a new language to learn for many team members +* Bad, because missing generics may be an issue and create less than readable code +* Bad, because it is still a garbage collected language +* Todo: check library availability + +=== Rust + +* Good, because it compiles to a single binary on many platforms +* Good, because no garbage collection +* Good, because it enforces a high level of security +* Bad, because a new language to learn for many team members +* Bad, because potentially very touch to find developers - arguably not a real drawback as people will need to be willing to learn something new anyway +* Todo: check library availability + +== Links + +* [Link type] [Link to ADR] +* … \ No newline at end of file diff --git a/adr/drafts/ADRx-choose_authorization_engine.adoc b/adr/drafts/ADRx-choose_authorization_engine.adoc new file mode 100644 index 000000000..016a55b46 --- /dev/null +++ b/adr/drafts/ADRx-choose_authorization_engine.adoc @@ -0,0 +1,102 @@ += Choose Authorization Engine +Doc Writer +v0.1, dd.mm.yyyy +:status: draft + +* Status: {status} +* Deciders: +** Florian Waibel +** Lars Francke +** Lukas Menzel +** Bernd Fondermann +** Oliver Hessel +** Sönke Liebau +* Date: xxx + +== Context and Problem Statement + +We need some form of authorization engine both for the products that are deployed via our stack as well as for our internal apis. +This engine should have the ability to express universal access controls, as it will need to be adapted to many different end products: + +* Stackable +* Hadoop +* Kafka +* Airflow +* Elasticsearch +* ... + +Depending on which option is chosen, there is a second, implicit, decision that is taken as part of this record: whether or not to include an identity provider. +Keycloak and Ranger both offer user management on top of authoriztion, whereas Open Policy Agent is purely an authorization engine. + +I'm not sure if we need to split this decision out into a separate ADR, but I suspect that it may make sense. +If Open Policy Agent is chosen as part of this ADR, at some point we need to decide whether we also need an identity provider and if so, which one we should pick. + + +== Decision Drivers + +* Availability of plugins for initial components or expected effort for implementation +* Flexibility of rule engine + +== Considered Options + +* Ranger +* Open Policy Agent +* Keycloak + + +== Decision Outcome + +Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. + +=== Positive Consequences + +* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] +* … + +=== Negative Consequences + +* [e.g., compromising quality attribute, follow-up decisions required, …] +* … + +== Pros and Cons of the Options + +=== Ranger + +https://ranger.apache.org/[Ranger] is the de facto default authorization tool in the big data ecosystem. +It offers existing integrations with a variety of tools and is used by the Cloudera offer as central access management component. + +* Good, because most necessary integrations already exist +* Good, existing know how applies +* Good, because it offers id provider functionality +* Bad, because adding new tools is complex +* Bad, because objects to authorize on need to be defined in code (see Open Policy Agent for comparison) +* Bad, because user synchronization mechanisms are fairly limited + +=== Open Policy Agent + +https://www.openpolicyagent.org/[Open Policy Agent] is a universal authorization engine that has become popular in the Kubernetes (but not exclusively) environment lately. +OPA defines ACLs in an abstract language called https://www.openpolicyagent.org/docs/latest/policy-language/[Rego] which allows keeping + + + +* Good, because relatively small effort to implement new tools +* Good, because very flexible system to define ACLs +* Bad, because no real HA concept +* Bad, because only one authorizer (Kafka) already implemented +* Bad, because would require additional identity provider + +=== Keycloak + +https://www.keycloak.org/[Keycloak] is based on a Wildfly application server and probably the most fully featured alternative of the ones discussed. +It allows integration with LDAP and AD, offers authorization, a clustered mode for high availability and much more. + +* Good, because gives a high degree of flexibility in adapting customers id solutions +* Good, because well established and widely used (GAIA-X, SCS) +* Bad, because no existing authorization plugins +* Bad, because objects to authorize on need to be defined in code (see Open Policy Agent for comparison) + + +== Links + +* [Link type] [Link to ADR] +* … \ No newline at end of file diff --git a/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc b/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc new file mode 100644 index 000000000..d4db9553b --- /dev/null +++ b/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc @@ -0,0 +1,84 @@ += Use xxx as storage backend for the orchestartor +Sönke Liebau +v0.1, 19.08.2020 +:status: draft + +* Status: {status} +* Deciders: +** Florian Waibel +** Lars Francke +** Lukas Menzel +** Bernd Fondermann +** Oliver Hessel +** Sönke Liebau +* Date: + +Technical Story: [description | ticket/issue URL] + +== Context and Problem Statement + +The orchestrator will need some form of persistent storage backend, for which a decision on the technology to be used has to be taken. +Our usage of this storage will most probably be extremely simple, even if a SQL database is chosen, the expectation is that it will be used fairly similar to a key value storage. + +== Decision Drivers + +* Availability of libraries for chosen programming language for the orchestrator +* How established is the backend at potential customers, will we need to deploy it? + + +== Considered Options + +* etcd +* Zookeeper +* SQL Database + +== Decision Outcome + + + +=== Positive Consequences + +* + +=== Negative Consequences + +* +== Pros and Cons of the Options + +=== etcd + +https://etcd.io/ + +* Good, because etcd is used by Kubernetes +** Likelyhood that it is already deployed +** Expertise with etcd by Kubernetes admins can be reused +* Good, because it offers watch functionality +* Good, because it offers consensus mechanisms +* Bad, because it has a hard size limit +* Bad, because it does not work well with large numbers of requests + +=== Zookeeper + +https://zookeeper.apache.org/ + +* Good, because it is well established and unterstood +* Good, because it offers watch functionality +* Good, because it offers consensus mechanisms +* Bad, because it offers no real benefit over etcd +* Bad, because it is known to have trouble with high volume of changes + +=== SQL Database + +* Good, because expertise and processes for some form of database will be present at pretty much any customer +** Backup +** HA +* Good, because deploying in integrated test/dev environment is easy with sqlite +* Bad, because we would need to potentially support multiple database vendors +** Postgres +** MS Sql +** Oracle +** … + + + +== Links diff --git a/adr/drafts/ADRx-decide_reuse_of_operators.adoc b/adr/drafts/ADRx-decide_reuse_of_operators.adoc new file mode 100644 index 000000000..be3dab910 --- /dev/null +++ b/adr/drafts/ADRx-decide_reuse_of_operators.adoc @@ -0,0 +1,70 @@ += Allow Reuse of Existing Kubernetes Operators +Sönke Liebau +v0.1, 19.08.2020 +:status: draft + +* Status: {status} +* Deciders: +** Florian Waibel +** Lars Francke +** Lukas Menzel +** Bernd Fondermann +** Oliver Hessel +** Sönke Liebau +* Date: + + +== Context and Problem Statement + +For some of the tools we plan to integrate there are existing operators that deploy these tools on Kubernetes. +Most notably these tools are: + +* Spark +* Kafka + +Some implementation effort may be avoided by reusing these operators instead of recreating the tool-specific functionality that is already implemented. +Since these operators are designed to work with Kubernetes and thus exclusively focused on containers some translation of data structures and processes would be necessary. + +== Decision Drivers + +* Keeping the implementation effort as low as realistically possible +* Keeping compatibility with Kubernetes as far as possible to ease a later move towards Kubernetes deployments +* Avoid hard dependencies on external projects that may force us to fork in case they break compatibility with us + +== Considered Options + +* Allow reuse of Kubernetes operators (would need to be decided individually for every tool) +* Don't reuse operators + +== Decision Outcome + +Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. + +=== Positive Consequences + +* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] +* … + +=== Negative Consequences + +* [e.g., compromising quality attribute, follow-up decisions required, …] +* … + +== Pros and Cons of the Options + +=== Allow reuse of Kubernetes operators + +* Good, because it saves implementation effort +* Good, because this forces us to consider Kubernetes compatibility repeatedly +* Bad, because we create a dependency on another project that may at some point break compatibility +* Bad, because we need to adapt to interfaces that have been designed specifically with containers in mind + +=== Don't reuse operators + +* Good, because it allows us to build our operators the way that works best for us +* Good, because we do not depend on the quality of external projects that may have implemented partial functionality (i.e. security) +* Bad, because we repeat work that has already been done + +== Links + +* https://kubernetes.io/docs/concepts/extend-kubernetes/operator/[Operator pattern description] From 965ddce58fc09b84c4846b135c8f1502f24348ef Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6nke=20Liebau?= Date: Mon, 14 Sep 2020 14:16:34 +0200 Subject: [PATCH 2/4] Update adr/drafts/ADRx-choose_agent_programming_language.adoc Co-authored-by: ohessel --- adr/drafts/ADRx-choose_agent_programming_language.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/adr/drafts/ADRx-choose_agent_programming_language.adoc b/adr/drafts/ADRx-choose_agent_programming_language.adoc index b5f82e4c0..3720c1c44 100644 --- a/adr/drafts/ADRx-choose_agent_programming_language.adoc +++ b/adr/drafts/ADRx-choose_agent_programming_language.adoc @@ -26,7 +26,7 @@ Which programming language should be used in the implementation of the agent tha ** File IO ** Network IO ** RPC depends on link:./ADRx-Protocol-to-use-for-communication-between-agent-and-orchestrator.html[ADRx-Protocol to use for communication between agent and orchestrator] -** SystemD +** systemd * IDE support * Debugging options @@ -81,4 +81,4 @@ Chosen option: "[option 1]", because [justification. e.g., only option, which me == Links * [Link type] [Link to ADR] -* … \ No newline at end of file +* … From 8806bad996b7824473965d285b57209747800724 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6nke=20Liebau?= Date: Mon, 14 Sep 2020 14:16:42 +0200 Subject: [PATCH 3/4] Update adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc Co-authored-by: ohessel --- adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc b/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc index d4db9553b..ea2e7d261 100644 --- a/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc +++ b/adr/drafts/ADRx-choose_orchestrator_storage_backend.adoc @@ -1,4 +1,4 @@ -= Use xxx as storage backend for the orchestartor += Use xxx as storage backend for the orchestrator Sönke Liebau v0.1, 19.08.2020 :status: draft From 0061aea64696f9b797a9947c29f20af336afc70b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B6nke=20Liebau?= Date: Mon, 14 Sep 2020 14:21:08 +0200 Subject: [PATCH 4/4] Addressed comment from Oliver. --- adr/drafts/ADRx-choose_authorization_engine.adoc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/adr/drafts/ADRx-choose_authorization_engine.adoc b/adr/drafts/ADRx-choose_authorization_engine.adoc index 016a55b46..c056ad951 100644 --- a/adr/drafts/ADRx-choose_authorization_engine.adoc +++ b/adr/drafts/ADRx-choose_authorization_engine.adoc @@ -75,7 +75,8 @@ It offers existing integrations with a variety of tools and is used by the Cloud === Open Policy Agent https://www.openpolicyagent.org/[Open Policy Agent] is a universal authorization engine that has become popular in the Kubernetes (but not exclusively) environment lately. -OPA defines ACLs in an abstract language called https://www.openpolicyagent.org/docs/latest/policy-language/[Rego] which allows keeping +OPA defines ACLs in an abstract language called https://www.openpolicyagent.org/docs/latest/policy-language/[Rego] which allows keeping authorization logic in the ACL definition, instead of source code. +This gives a much higher degree of abstraction and thus flexibility than having to hard-code the logic for every application.