SF Documentation

1. Application

2. Introduction

2.1 Document purpose

This document is a low level design - LLD which aims to describe how the architecture evoked in high level design - HLD will be implemented. This document will describe the protocols used in the target architecture, how to implement them and any modifications made to their default behavior. Once validated by Thales, this document will then serve as a basis for the implementation of configurations on equipment.

2.2 Document scope

This document is not a manual and is not intended to replace the reference literature describing with great precision all network protocols.

The protocols used will be briefly described as well as the modifications made to their default behavior.

2.3 Referenced documentation

3. Component general description

This component is part of Software Factory as a Product (SWaaP), and it is visible in the TASD .

This component permits to expose Software Factory Documentation services to any Software engineer (end user of SWaaP) and any Software Factory service owner (users of SWaaP). Documentation service is exclusively exposed using its UI.

4. Functional & Business Requirements

No formal list of requirements has been expressed by clients. It is designed and developed based on business use cases.

4.2 Prerequisites

Every prerequisites of the product are applicable to this component, but not PRE_008 (Object Storage), nor PRE_014 (SMTP), nor PRE_015 (Database). See the TASD .

4.3 Variability

This component have no variability.

5. Architecture decision record

Here is a list of decisions:

Table 3 - List of architecture decision record.

5.1 ADR-DOCS-001: Add Documentation as a component of the product

5.1.1 Status: Accepted

• See ADR004 in TASD .

5.1.2 Context

• Existence of a documentation component embryo deploying the container from https://docs.thalesdigital.io, but not managed as a product and not updated.
• Need to be able to access to documentation aside the Software Factory, without accessing internet, and in consistency with SWaaP deployed version.

5.1.3 Decision

• Introduce Software Factory Documentation in the product.

5.1.4 Consequences

• Add Docs to the product

5.2 ADR-DOCS-002: Choose framework

5.2.1 Status: Accepted

• ADR-01 of Software Practices

5.2.2 Context

• Existense of several sites and technology: Gatsby, Docusaurus, Hugo, Antora.
• Decision to manage as much as possible documentation as code.
• Decision to mutualize public sites in one.
• Analyze of various framework done

5.2.3 Decision

• Selection of Hugo with Docsy

5.2.4 Consequences

• Validate the corresponding merge request

5.3 ADR-DOCS-003: Deployment strategy

5.3.1 Status: Accepted

• 23/07/2025 Decision meeting MoM

5.3.2 Context

Need to address a main point to distribute Software Factory product documentation, Software Engineering practices and tooling 101 toturials to any Thales employee or internal contractor whatever he already use it or not, its endpoint, its location.

The Software Factory tribe assume that the final target is the same as current doc , that is to say part of Software Factory TDP C2 deployment and available to any Thales employe that can access to TDP C2.

With current unclear responsibility model and not well support existing infrastructure a plan B in the mean time is needed.

Alternatvies and pro/con can be:

5.3.3 Decision

• Plan A: take ownership to the current deployment of docs ; if no perspective until August 14th, go to plan B
• Plan B: deploy in Azure static pages.

5.3.4 Consequences

• Smartchitect squad is contacting CTO to take the ownership of current deployment of docs .
• Smart Fusion squad adds SAML authentication for plan A.
• Craftmansheep squad evaluates feasibility of Azure static pages .

5.4 ADR-DOCS-004: Split user and admin data or put RBAC

5.4.1 Status: Rejected

• 07/10/2025 Decision meeting MoM

5.4.2 Context

sf-docs presents:

• end-user documentation with tools, practices, instructions, and trainings,
• admin documentation with operating guides, TASD and LLD.

All data presented has C2 sensitivity level. Moreover, there is no project-specific data.

Therefore, “need-to-know” if not applicable here.

As there is no RBAC in sf-docs, any of the 3 roles that can access sf-docs can read all the documentation.

5.4.3 Decision

As there is no data in sf-docs other than C2 or project-specific data, there is no need to implement role-based access control (RBAC).

5.4.4 Consequences

Continue to keep the documentation source in an innersource project.

Continue to present all the data to every Thales employee.

5.5 ADR-DOCS-005: Introduce authentication

5.5.1 Status: Accepted

• 23/01/2026 Scoping result

5.5.2 Context

sf-docs as a component is a static web site based on alpine.nginx.

Currently it supports only basic authentification. All data presented has C2 sensitivity level.

5.5.3 Decision

Have to set an authentication in accordance with Thales IAM standards.

5.5.4 Consequences

• Introduce authentication based on oauth2-proxy.
• By default helm config set for IAM but with any default value that have to be specified by platform.
• Still use basic authentication on development environments.
• Use TDP IAM authentication on integration platform.

6. Architecture description

6.1 Business architecture and allocation to services

You will find in Figure 1 business architecture for software code and CI/CD engineering allocated to services:

Figure 1 - Business architecture allocated to services.

Note: in dash, external items.

6.2 Application architecture

Physical architecture is described in Figure 2 :

Figure 2 - Physical architecture

Docs is using these external services:

• A Software Factory or mirror for deployment (PRE_001)
• Kubernetes with Flux (PRE_002, PRE_003)
• Persistent storage to store the configuration and cache (PRE_004)
• Ingress with TLS and dns resolution associated for one entry point and certificates, classically https://docs.SF-DOMAIN (PRE_005, PRE_006, PRE_007)
• In option, IAM (PRE_009); we recommend OIDC SSO. See IAM

Pod docs-0 is running a developed container image. This images is:

• based on alpine.nginx that is built by Thales Container Base Images Innersource project.
• enriched with static html site.

This site is generated from markdown and AsciiDoc using AsciiDoctor and open source Hugo (Apache License V2). Theme used is Docsy .

Component is build with this pipeline:

6.2.1 User management

This role matrix has been defined in TASD:

6.2.2 RACI

In addition of global RACI (Responsible, Accountable, Consulted, Informed) of the SWaaP defined in TASD:

6.3 Delivery

Component is part of the Software Factory as a Product (SWaaP) delivery. See TASD for more details.

• Component repository
• Latest version
  • Component registry
  • Helm chart repository
• Reference Component repository
• SWaaP integration part
• Release changelog

6.4 Infrastructure architecture

6.4.1 Software Factory API

Here is a list of services that can be integrated with the Documentation.

7. Operational and maintenance

In this chapter you will find strategy and policy. Detail implementation will be described in the SCOM.

7.1 Life cycle policy

Cadence of version is describe in the Product Lifecycle .

7.2 License

No license is required for this component.

7.3 Deployment

The component is deployed as a standard component using Flux and SWaaP packaging. See TASD for more details.

7.4 IAM

We support and recommend integration with IAM using OIDC SSO. This configuration can be done in deployment.

7.5 Scaling

Vertical and horizontal scaling is supported. See Capacity planning in SCOM-Documentation

7.6 Backup / restore

This component is stateless and no data is recorded. In consequence no backup is required, as it can be redeployed as code.

7.7 Monitoring

No particular monitoring is suggested. Classical one with time and status respond of ingress is enough.

7.8 Logging

We recommend to apply the platform logging & SOC management strategy.