akyriako/architecture-center
1
0
Fork 0
forked from docs/architecture-center
Code Pull Requests Activity

changes based on review comments, removed tpls

Browse Source
This commit is contained in:
Kyriakos Akriotis 2024-02-14 12:34:21 +01:00
parent 62311a7cae
commit 2e65ff9e09
10 changed files with 28 additions and 397 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/blueprints/source/best-practices/index.rst
View File

@ -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

2
doc/blueprints/source/best-practices/network/index.rst
View File

@ -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.

19
doc/blueprints/source/best-practices/security/cce_vault.rst
View File

@ -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
<https://www.hashicorp.com/resources/what-is-secret-sprawl-why-is-it-harmful>`_,
@ -18,6 +21,9 @@ usually introduces a problem of the so-called `Secret Zero
<https://www.hashicorp.com/resources/secret-zero-mitigating-the-risk-of-secret-introduction-with-vault>`_
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
<https://www.vaultproject.io/docs/secrets/kv/kv-v2>`_

3
doc/blueprints/source/best-practices/security/index.rst
View File

@ -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

7
doc/blueprints/source/index.rst
View File

@ -2,7 +2,12 @@
Blueprints
==========
<PLACEHOLDER>
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
<https://open-telekom-cloud.com/service-description>`_, they are tested and
validated recommendations from our experts.
.. toctree::
:maxdepth: 1

2
doc/blueprints/source/use-cases/index.rst
View File

@ -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.

124
doc/source/_templates/article_external.tpl
View File

File diff suppressed because it is too large Load Diff

85
doc/source/_templates/article_internal.tpl
View File

@ -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 <https://www.t-systems.com>`_
`Link2 <https://www.t-systems.com>`_
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 <https://www.t-systems.com>`_
`Link2 <https://www.t-systems.com>`_
.. References
References
==========
| > *Add site-relative links to Architecture Center articles*
| > *Add links to external or third-party resources*
.. seealso::
`Link1 <https://www.t-systems.com>`_
`Link2 <https://www.t-systems.com>`_
| > **REMOVE ALL THE LINES THAT START WITH "| >"**

168
doc/source/_templates/solution.tpl
View File

File diff suppressed because it is too large Load Diff

11
doc/source/index.rst
View File

@ -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