205 lines
6.7 KiB
PHP
205 lines
6.7 KiB
PHP
Security Design
|
|
===============
|
|
|
|
.. graphviz:: dot/docsportal_sec.dot
|
|
:caption: Docs portal secutiry architecture
|
|
|
|
Security Architecture
|
|
---------------------
|
|
|
|
Documentation portal takes care of making documentation publicly available.
|
|
This means that the content it is processing will be publicly available. No
|
|
care about avoiding placing sensitive information from git repositories is
|
|
taken and it is explicitly in the responsibility of each individual project
|
|
maintainers to ensure no sensitive information land in git.
|
|
|
|
Ensuring, that only checked and approved content will be merged in git and
|
|
published is a primary responsibility of :ref:`Zuul` which applies also
|
|
:ref:`git_control` to manage required conditions that need to be fulfilled on
|
|
every pull request of every project.
|
|
|
|
Separation
|
|
----------
|
|
|
|
The project is implemented as a combination of multiple software
|
|
and solution components communicating with each other. Those
|
|
components are installed physically separated from each other
|
|
with no direct connectivity except of public HTTPS.
|
|
|
|
* Web Server
|
|
|
|
* Nginx web server accepts HTTP protocol requests. It rewrites
|
|
the request to a destination on the Remote Storage.
|
|
|
|
* It performs remote request to fetch the requested content
|
|
and serves it back to the initial requestor.
|
|
|
|
* Depending on the content accessibility web server is either exposed
|
|
directly to the web or behind additional reverse proxy implementing
|
|
required security limitations.
|
|
|
|
* Storage
|
|
|
|
* OpenStack Swift storage. Practically this can be any other object storage
|
|
which allows web access.
|
|
|
|
* Zuul CI/CD writes approved content into the storage
|
|
destination.
|
|
|
|
* Web Server fetches the content.
|
|
|
|
* The content in the Storage for the Documentation Portal is by
|
|
definition public content (not protected by any additional ACLs).
|
|
|
|
* If the content is not designed to be publicly available content in the
|
|
Storage must be protected by ACLs. This in turn will require enabling web
|
|
server to access this content (i.e. swift-proxy in the case of using
|
|
OpenStack Swift).
|
|
|
|
* :ref:`zuul`
|
|
|
|
* Zuul installation manages git projects and implements
|
|
configured CI rules in order to ensure that only checked and
|
|
approved content will be merged. Default configuration
|
|
forbids anybody (except of Zuul Administrators) to bypass
|
|
required checks and merge content manually
|
|
* Once all the prerequisites are fulfilled Zuul merges Pull
|
|
Request, builds documentation and pushes it to storage with
|
|
dedicated credentials.
|
|
* Only git projects explicitly included in the Zuul tenant are
|
|
being respected. Registered git projects with disabled
|
|
branch protection rules are ignored.
|
|
|
|
* `GitHub <https://github.com>`_
|
|
|
|
* An external git hosting provider.
|
|
* Projects in the GitHub organization are managed by `dedicate process
|
|
<https://docs.otc-service.com/system-config/gitcontrol.html>`_
|
|
|
|
Interface Description
|
|
---------------------
|
|
|
|
The only public facing interface is the regular Web using HTTPS (automatic
|
|
forwarding from HTTP).
|
|
|
|
Tenant Security
|
|
---------------
|
|
|
|
Documentation Portal does not support tenants concept. All documents that are hosted
|
|
on the Help Center are placed in a dedicated storage (as public content).
|
|
Instead a dedicated instance of the documentation portal is deployed for
|
|
isolating particular documentation areas.
|
|
|
|
O&M Access Control
|
|
------------------
|
|
|
|
Only users enabled in the :git_file:`inventory/base/group_vars/all.yaml` are
|
|
able to login to the underlaying infrastructure. Direct access to the hosts is
|
|
only possible through the :ref:`Bridge` host which serves as a bastion host.
|
|
|
|
Logging and Monitoring
|
|
----------------------
|
|
|
|
Every component of the HelpCenter produces own logs.
|
|
|
|
* haproxy log (VM service logs)
|
|
* nginx log (VM or Kubernetes POD log)
|
|
* Swift proxy and storage service logs
|
|
* Zuul logs
|
|
|
|
* public job logs (test build log file)
|
|
* executor log
|
|
* scheduler log
|
|
|
|
Patch Management
|
|
----------------
|
|
|
|
The service consists of OpenSource elements only. Whenever new release of any
|
|
software element (haproxy, nginx, zuul) is identified a Pull Request to this
|
|
repository need to be created to update the software. Pathing of the
|
|
underlaying VM (haproxy) is executed as a regular job applying all the existing
|
|
OS updates.
|
|
|
|
Hardening
|
|
---------
|
|
|
|
All configuration files for the hosts, Cloud Load Balancer configuration and K8
|
|
configuration is part of this repository. Every VM is managed by the System
|
|
Config project applying the same hardening rules to evenry host according to
|
|
the configuration. As such system hardenings are dictated by Deutsche Telekom
|
|
Hardening policies.
|
|
|
|
Certificate Handling
|
|
--------------------
|
|
|
|
SSL Certificates are obtained using Let's Encrypt Certificate authority.
|
|
Following is important:
|
|
|
|
* Certificate for the K8 deployment can be managed by the
|
|
`CertManager <https://cert-manager.io/>`_ deployed in
|
|
the Kubernetes cluster. This is achieved by placing
|
|
Kubernetes annotation on the deployment.
|
|
* Alternatively SSL Certificate for the K8 installation may be generated on the
|
|
deployment server and provided into the K8 as secrets.
|
|
* Certificates for the other involved components (Zuul,
|
|
Swift) are managed by the corresponding components
|
|
themselves.
|
|
|
|
Backup and Restore
|
|
------------------
|
|
|
|
No backup/restore procedure exists besides Swift backup/restore. Sources for
|
|
the documents are stored in GitHub in a raw form with all modification history.
|
|
Whenever it is required to restore document to the particular point in time a
|
|
pull request can be created restoring current version to a particular state in
|
|
history.
|
|
From a disaster recovery point of view a fresh generation of the documents from
|
|
sources can be used. The same approach can be applied periodically to ensure
|
|
generated documents are always up-to-date and matching current document
|
|
stylizations.
|
|
|
|
User and Account management
|
|
---------------------------
|
|
|
|
No user accounts on the documentation portal are existing. Only a regular
|
|
anonym access to the service is possible. No cookies or local web browser storage is used.
|
|
|
|
Communication Matrix (external)
|
|
-------------------------------
|
|
|
|
Complete communication between Help Center elements is happening as with
|
|
external components (using HTTPS).
|
|
|
|
Depending on the requirements additional reverse proxy may be installed in from
|
|
of the web server to provide additional hardening or other required isolation
|
|
measures. Also in this case communication between reverse proxy and the web
|
|
server is happening as HTTPS traffic.
|
|
|
|
.. list-table::
|
|
|
|
* - From/To
|
|
- Web Server
|
|
- Storage
|
|
- Zuul
|
|
- GitHub
|
|
* - WebServer
|
|
- N/A
|
|
- HTTPS
|
|
- N/A
|
|
- N/A
|
|
* - Storage
|
|
- N/A
|
|
- N/A
|
|
- N/A
|
|
- N/A
|
|
* - Zuul
|
|
- N/A
|
|
- HTTPS
|
|
- N/A
|
|
- HTTPS
|
|
* - GitHub
|
|
- N/A
|
|
- N/A
|
|
- HTTPS
|
|
- N/A
|