From 2e65ff9e09f00b73f2725f4a64562ec27ac27c4e Mon Sep 17 00:00:00 2001 From: Kyriakos Akriotis Date: Wed, 14 Feb 2024 12:34:21 +0100 Subject: [PATCH] changes based on review comments, removed tpls --- .../source/best-practices/index.rst | 4 +- .../source/best-practices/network/index.rst | 2 +- .../best-practices/security/cce_vault.rst | 19 +- .../source/best-practices/security/index.rst | 3 +- doc/blueprints/source/index.rst | 7 +- doc/blueprints/source/use-cases/index.rst | 2 +- doc/source/_templates/article_external.tpl | 124 ------------- doc/source/_templates/article_internal.tpl | 85 --------- doc/source/_templates/solution.tpl | 168 ------------------ doc/source/index.rst | 11 +- 10 files changed, 28 insertions(+), 397 deletions(-) delete mode 100755 doc/source/_templates/article_external.tpl delete mode 100755 doc/source/_templates/article_internal.tpl delete mode 100755 doc/source/_templates/solution.tpl diff --git a/doc/blueprints/source/best-practices/index.rst b/doc/blueprints/source/best-practices/index.rst index 341aece..48efc3d 100644 --- a/doc/blueprints/source/best-practices/index.rst +++ b/doc/blueprints/source/best-practices/index.rst @@ -2,8 +2,8 @@ Best Practices ============== -Welcome Open Telekom Cloud Architecture Center Best Practices. -Here we provides crucial guidelines for optimizing cloud-based solutions with emphasis to architectural principles that +Welcome to the Open Telekom Cloud Architecture Center Best Practices. +Here we provide crucial guidelines for optimizing cloud-based solutions with emphasis to architectural principles that enhance reliability, scalability, and security. Explore our recommended strategies for resource management, such as efficient utilization of compute and storage resources. Gain insights into designing for high availability and fault tolerance to ensure robust system performance. This section serves as a valuable resource for architects and developers diff --git a/doc/blueprints/source/best-practices/network/index.rst b/doc/blueprints/source/best-practices/network/index.rst index 13ad2c9..459c2df 100644 --- a/doc/blueprints/source/best-practices/network/index.rst +++ b/doc/blueprints/source/best-practices/network/index.rst @@ -5,7 +5,7 @@ Network Best Practices outline key strategies for optimizing network configurati resilient and high-performance network architectures, including considerations for security and scalability. Learn about best practices for leveraging Virtual Private Clouds (VPCs), network segmentation, and load balancing to enhance overall network efficiency. This section serves as a valuable resource for architects and network administrators, -providing insights into building robust and secure network infrastructures within the Open Telekom Cloud environment, +providing insights for a robust network strategy within the Open Telekom Cloud environment, ensuring reliable and seamless connectivity for applications and services. diff --git a/doc/blueprints/source/best-practices/security/cce_vault.rst b/doc/blueprints/source/best-practices/security/cce_vault.rst index 4b2a95c..be70070 100644 --- a/doc/blueprints/source/best-practices/security/cce_vault.rst +++ b/doc/blueprints/source/best-practices/security/cce_vault.rst @@ -2,14 +2,17 @@ Secrets management with CCE and Hashicorp Vault =============================================== +Overview +======== + Most modern IT setups are composed of several subsystems like databases, object stores, master controller, node access, and more. To access one component from another, some form of credentials are required. Configuring and storing these secrets directly in the components is considered as an anti-pattern, since a -vulnerability of one component may iteratively affect the security of the whole +vulnerability of one component may iteratively and transitively affect the security of the whole setup. -With centralized secret management it becomes unnecessary to keep secrets used +With centralized secret management in place, it's not necessary to keep secrets used by various applications spread across DevOps environments. This helps to close some security attack vectors (like `secret sprawl `_, @@ -18,6 +21,9 @@ usually introduces a problem of the so-called `Secret Zero `_ as a key to the key storage. +Solution Description +==================== + Vault is an open-source software, provided and maintained by Hashicorp, that addresses this very problem. It is considered one of the reference solutions for it. This article demonstrates how to utilize infrastructure authorization @@ -25,12 +31,7 @@ with Hashicorp Vault in an CCE-powered setup. As an example workload, we deploy a Zookeeper cluster with enabled TLS protection. Certificates for Zookeeper are stored in Vault, and they oblige required practices like rotations or audits. Zookeeper can easily be replaced by any other component that requires access to -internal credentials. - -Overview -======== - -TLS secrets are kept in the Vault. They are being read by Vault Agent component +internal credentials. TLS secrets are kept in the Vault. They are being read by Vault Agent component running as a sidecar in Zookeeper service pod and writes certificates onto the file system. Zookeeper services reads certificates populated by Agent. Vault Agent is configured to use password-less access to Vault. Further in the @@ -110,7 +111,7 @@ mitigates this risk. Populating secrets in Vault =========================== -Within Vault there are two possibilities to access TLS certificates: +Vault offer two options to access TLS certificates: * Store certificate data in the `KeyValue store `_ diff --git a/doc/blueprints/source/best-practices/security/index.rst b/doc/blueprints/source/best-practices/security/index.rst index e4fc5bb..3a38ea9 100644 --- a/doc/blueprints/source/best-practices/security/index.rst +++ b/doc/blueprints/source/best-practices/security/index.rst @@ -6,7 +6,8 @@ implementing robust identity and access management, encryption protocols, and ne secure data at rest and in transit, as well as strategies for monitoring and responding to security incidents. This section is a crucial resource for architects and cybersecurity professionals, providing insights into designing and maintaining resilient security postures within the Open Telekom Cloud, ensuring the -confidentiality, integrity, and availability of sensitive information. +confidentiality, integrity, high availability, scalability, robustness and resilience of sensitive information and +critical infrastructure. .. toctree:: :maxdepth: 1 diff --git a/doc/blueprints/source/index.rst b/doc/blueprints/source/index.rst index 3ede24a..30f487d 100644 --- a/doc/blueprints/source/index.rst +++ b/doc/blueprints/source/index.rst @@ -2,7 +2,12 @@ Blueprints ========== - +Users sometimes identify use cases that can be solved in a standardized way to +save research time and effort. Architecture Center Blueprints offer a collection of series of best practices, +curated by the Open Telekom Cloud engineering and architecture teams. While +they are not covered directly by the `Service description +`_, they are tested and +validated recommendations from our experts. .. toctree:: :maxdepth: 1 diff --git a/doc/blueprints/source/use-cases/index.rst b/doc/blueprints/source/use-cases/index.rst index 7e6277b..601e9dc 100644 --- a/doc/blueprints/source/use-cases/index.rst +++ b/doc/blueprints/source/use-cases/index.rst @@ -1,7 +1,7 @@ Use Cases ========= -Welcome Open Telekom Cloud Architecture Center Use Cases. Here you can find tailored solutions and +Welcome to Open Telekom Cloud Architecture Center Use Cases. Here you can find tailored solutions and practical implementations for a range of scenarios. Explore real-world examples demonstrating the versatility and optimal application and infrastructure design using our cloud services. This section serves as a comprehensive resource for architects, offering insights into how to adapt and optimize cloud solutions for specific business needs. diff --git a/doc/source/_templates/article_external.tpl b/doc/source/_templates/article_external.tpl deleted file mode 100755 index cdaf1fd..0000000 --- a/doc/source/_templates/article_external.tpl +++ /dev/null @@ -1,124 +0,0 @@ -. meta:: - :description: add a SEO description here - :keywords: add SEO keywords here, and list additionally all OTC services used - -================== -Article (External) -================== - -.. Introduction - -Introduction -============ - -| > *There are no further requirements for an article except to include the following sections at the **end**, and to follow all general Open Telekom Cloud Architecture Center content requirements.* -| > *An Open Telekom Cloud Architecture Center article template, for **external** creators, requires the following sections at the end of the article:* - -.. topic:: TL;DR - - | >> Make a brief summary of what is the article about - -.. Main Article - -.. Components - -| > *No header required here* -| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.* - -.. Sections 1..n - -| > You can name the Section titles as it seems fit to the workflow of the article. - -Section 1 -========= - -Section 2 -========= - -Section n -========= - - -.. Authors and Contributors - -Contributors -============ - -| > *(Expected, but it could be optional if all the contributors would prefer not to be mentioned)* -| > *Start with the explanation text (same for every article), in italics.* -| > *Then include the "Principal authors" list and the "Additional contributors" list (if there are additional contributors) (all in plain text, not italics or bold).* -| > *Link each contributor's name to the person's LinkedIn profile.* -| > *After the name, place a pipe symbol ("|") with spaces, and then enter the person's title.* -| > *Do not include any additional links except the LinkedIn profile URL.* - -*It was originally written by the following contributors:* - -Principal authors: - -.. admonition:: Authors - - `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ - - `(Author 2 Name) | (Title, such as "Cloud Architect") `_ - -| > *Only the primary authors.* -| > *List them alphabetically, by last name.* -| > *Use this format: **Fname Lname**.* -| > *If the article gets rewritten, keep the original authors and add in the new one(s).* - -Other contributors: - -| > *Include contributing (but not **primary**) authors, major editors (not minor edits), and technical reviewers.* -| > *List them alphabetically, by last name. Use this format: **Fname Lname**.* - -.. admonition:: Contributors - - `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ - - `(Author 2 Name) | (Title, such as "Cloud Architect") `_ - - -.. Next steps & Related Resources - -Next Steps -========== - -| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)* -| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources* -| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - -Resources -========= - -.. Resources - -| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - - -.. References - -References -========== - -| > *Add site-relative links to Architecture Center articles* -| > *Add links to external or third-party resources* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - -| > **REMOVE ALL THE LINES THAT START WITH "| >"** diff --git a/doc/source/_templates/article_internal.tpl b/doc/source/_templates/article_internal.tpl deleted file mode 100755 index c5eef08..0000000 --- a/doc/source/_templates/article_internal.tpl +++ /dev/null @@ -1,85 +0,0 @@ -. meta:: - :description: add a SEO description here - :keywords: add SEO keywords here, and list additionally all OTC services used - -================== -Article (Internal) -================== - -.. Introduction - -Introduction -============ - -| > *There are no further requirements for an article except to include the following sections at the **end**, and to follow all general Open Telekom Architecture Center content requirements.* -| > *An Open Telekom Cloud Architecture Center article template, for **external** creators, requires the following sections at the end of the article:* - -.. topic:: TL;DR - - | >> Make a brief summary of what is the article about - -.. Main Article - -.. Components - -| > *No header required here* -| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.* - -.. Sections 1..n - -| > *You can name the Section titles as it seems fit to the workflow of the article.* - -Section 1 -========= - -Section 2 -========= - -Section n -========= - - -.. Next steps & Related Resources - -Next Steps -========== - -| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)* -| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources* -| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - -Resources -========= - -.. Resources - -| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aformentioned order* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - - -.. References - -References -========== - -| > *Add site-relative links to Architecture Center articles* -| > *Add links to external or third-party resources* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - -| > **REMOVE ALL THE LINES THAT START WITH "| >"** diff --git a/doc/source/_templates/solution.tpl b/doc/source/_templates/solution.tpl deleted file mode 100755 index 7bf0c94..0000000 --- a/doc/source/_templates/solution.tpl +++ /dev/null @@ -1,168 +0,0 @@ -. meta:: - :description: add a SEO description here - :keywords: add SEO keywords here, and list additionally all OTC services used - -======== -Solution -======== - -.. Introduction - -Introduction -============ - -| > *In this section, include 1-2 sentences to briefly explain this architecture.* -| > *The full scenario info will go in the "Scenario details" section* -| > *Include a TL;DR;* - -.. topic:: TL;DR - - | >> Make a brief summary of the scenario details and what are going to achieve with this solution. INSIDE THIS BOX - -.. Architecture - -Architecture -============ - -| > *Architecture diagram goes here. Use the following format:* - -.. image:: https://docs.otc.t-systems.com/cloud-container-engine/umn/_images/en-us_image_0000001172392670.png - -| > *Note: if there is a PowerPoint or a Visio attachment for the Architecture Diagram include it in the Resources section for download* - -.. Scenario - -Scenario -======== - -| > *In this section, include a numbered list that annotates/describes the scenario steps of the solution. Explain what each step does.* -| > *Start from the user or external data source, and then follow the flow through the rest of the solution* - -| > Examples: - - #. Admin 1 adds, updates, or deletes an entry in Open Telekom Cloud console. - #. Admin 1 commits and syncs the code changes to forked repository. - #. Admin 1 creates a pull request (PR) to merge the changes to the main repository. - #. The build pipeline runs on the PR. - #. Check the status in Open Telekom Cloud console. - -.. Components - -| > *No header required here* -| > *(Expected to list all the Open Telekom Cloud components used, but it could be optional if it just an architectural paradigm.* - -.. Scenario details - -| > *Scenario details* -| > *This should be an explanation of the business problem and why this scenario was built to solve it.* -| > *What prompted them to solve the problem?* -| > *What services were used in building out this solution?* -| > *What does this example scenario show? What are the customer's goals?* -| > *What were the benefits of implementing the solution?* - -.. Sections 1..n - -| > *You can name the Section titles as it seems fit to the workflow of the article.* - -Section 1 -========= - -Section 2 -========= - -Section n -========= - -.. Potential use cases - -Potential Use Cases -=================== - -| > *What industry is the customer in? Use the following industry keywords, when possible,* -| > *to get the article into the proper search and filter results: retail, finance, manufacturing, healthcare, government, energy, telecommunications, education, automotive, nonprofit, game, media (media and entertainment), travel (includes hospitality, like restaurants), facilities (includes real estate), aircraft (includes aerospace and satellites), agriculture, and sports.* -| > *Are there any other use cases or industries where this would be a fit?* -| > *How similar or different are they to what's in this article?* - -.. Authors and Contributors - -Contributors -============ - -| > *(Expected, but it could be optional if all the contributors would prefer not to be mentioned)* -| > *Start with the explanation text (same for every article), in italics.* -| > *Then include the "Principal authors" list and the "Additional contributors" list (if there are additional contributors) (all in plain text, not italics or bold).* -| > *Link each contributor's name to the person's LinkedIn profile.* -| > *After the name, place a pipe symbol ("|") with spaces, and then enter the person's title.* -| > *Do not include any additional links except the LinkedIn profile URL.* - -*It was originally written by the following contributors:* - -Principal authors: - -.. admonition:: Authors - - `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ - - `(Author 2 Name) | (Title, such as "Cloud Architect") `_ - -| > *Only the primary authors.* -| > *List them alphabetically, by last name.* -| > *Use this format: **Fname Lname**.* -| > *If the article gets rewritten, keep the original authors and add in the new one(s).* - -Other contributors: - -| > *Include contributing (but not **primary**) authors, major editors (not minor edits), and technical reviewers.* -| > *List them alphabetically, by last name. Use this format: **Fname Lname**.* - -.. admonition:: Contributors - - `(Author 1 Name) | (Title, such as "Cloud Engineer") `_ - - `(Author 2 Name) | (Title, such as "Cloud Architect") `_ - - -.. Next steps & Related Resources - -Next Steps -========== - -| > *(Expected, but it could be optional if you don't want the article stops here and doesn't connect with other resources)* -| > *Add site-relative links to Architecture Center related articles but NOT to external or third-party resources* -| > *If there are additional resources like Cloud Topology Designer solution or Github repos, list them first with the aforementioned order* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - -Resources -========= - -.. Resources - -| > *If there are additional deployable resources like Cloud Topology Designer solution or Github repos, list them first with the aformentioned order* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - - -.. References - -References -========== - -| > *Add site-relative links to Architecture Center articles* -| > *Add links to external or third-party resources* - -.. seealso:: - - `Link1 `_ - - `Link2 `_ - -| > **REMOVE ALL THE LINES THAT START WITH "| >"** diff --git a/doc/source/index.rst b/doc/source/index.rst index 74d6649..ef833a0 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -1,11 +1,12 @@ Architecture Center =================== -Lorem ipsum dolor sit amet, consectetur adipiscing elit. -Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. -Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris. -Duis aute irure dolor in reprehenderit in voluptate velit esse cillum. -Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt. +Welcome to the Open Telekom Cloud Architecture Center. + +Unlock the full potential of Open Telekom Cloud with our comprehensive collection of resources, best practices, +and expert guidance material. Whether you're new to the cloud landscape or an experienced professional, +our Architecture Center is designed to empower you in building robust, reliable, scalable, innovative and cost-efficient +architectures on Open Telekom Cloud. .. directive_wrapper:: :class: container-sbv