Skip to content

Commit

Permalink
xml/obs_ag_security_concepts.xml: correct rewritten xml:id values
Browse files Browse the repository at this point in the history 
The xml:id values in the XML file were rewritten, but not in the
correct way.

Signed-off-by: Nathan Cutler <[email protected]>
  • Loading branch information
@smithfarm
smithfarm committed Jul 21, 2024
1 parent 5772177 commit ca19486
Showing 1 changed file with 25 additions and 25 deletions.
50 changes: 25 additions & 25 deletions xml/obs_ag_security_concepts.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,11 +18,11 @@
However, optional services to integrate remote resources exist as well. These resources
are either mirrored and stored in revision control system or just cached.
</para>
<sect2 xml:id="network-setup">
<sect2 xml:id="general-paradigm-network-setup">
<title>Frontend</title>
<para>The API and web interface frontends is the only part which must be accessible from
public network. A SSL/TLS certificate is highly recommended.</para>
<sect3 xml:id="network-access">
<sect3 xml:id="general-paradigm-network-setup-network-access">
<title>Access to Mirror Servers</title>
<para>The following services require access to stage servers. These servers
can be used to publish content without the need to make &obs; server parts
Expand All @@ -40,7 +40,7 @@
</listitem>
</itemizedlist>
</sect3>
<sect3 xml:id="public-network-access">
<sect3 xml:id="general-paradigm-network-setup-public-network-access">
<title>Access to the Public Network</title>
<para>The following services may require access to the public network.</para>
<itemizedlist>
Expand All @@ -67,14 +67,14 @@
</listitem>
</itemizedlist>
</sect3>
<sect3 xml:id="worker-network">
<sect3 xml:id="general-paradigm-network-setup-worker-network">
<title>Worker network</title>
<para>It is recommended to run the &obs; workers in an isolated network. This is
an additional security mechanism in case of a security breach on a worker.
This network needs access to the source and repository servers of the &obs;
backend, but nowhere else.</para>
</sect3>
<sect3 xml:id="signd-network">
<sect3 xml:id="general-paradigm-network-setup-signd-network">
<title>Signer network</title>
<para>It is recommended to run the signd on an isolated host. The signer services
need to stay on the &obs; backend servers, they are just used for scheduling
Expand All @@ -88,7 +88,7 @@
backend server components (source server and publisher).</para>
</sect3>
</sect2>
<sect2 xml:id="build-env">
<sect2 xml:id="general-paradigm-build-env">
<title>Build Environment</title>
<para>The build environment is created by obsworker instances via the build script.
Inside the build instances unverified and potentially harmful code is executed.
Expand All @@ -112,7 +112,7 @@
source packages are rebuildable without root permissions.
</para>
</sect2>
<sect2 xml:id="source-revision-system">
<sect2 xml:id="general-paradigm-source-revision-system">
<title>Source Revision System</title>
<para>The source revision storage system is part of &obs;. The identification of sources
still happens using MD5 sums for historic reasons. MD5 is considered to be still
Expand All @@ -126,7 +126,7 @@
builds, but it should be avoided for base projects.
</para>
</sect2>
<sect2 xml:id="permission-handling">
<sect2 xml:id="general-paradigm-permission-handling">
<title>Permission Handling</title>
<para>Authorization for write operations is done via the maintainer role on package
or project level. On project level the projects are organized in namespaces
Expand All @@ -136,7 +136,7 @@
top level namespaces (for example, openSUSE: namespace in our reference instance).
</para>
</sect2>
<sect2 xml:id="signature-handling">
<sect2 xml:id="general-paradigm-signature-handling">
<title>Signature Handling</title>
<para>Signatures are used to proof the origin of a shipment independent of
&obs; instance. Once the <systemitem>signd</systemitem> daemon has
Expand Down Expand Up @@ -187,11 +187,11 @@
separated via network or virtualization mechanics.
</para>

<sect2 xml:id="public-zone">
<sect2 xml:id="trust-zones-public-zone">
<title>Public Zones</title>
<para>Public zones are areas where any code under user control is running.
</para>
<sect3 xml:id="external-network">
<sect3 xml:id="trust-zones-public-zone-external-network">
<title>External Network</title>
<para>
This can be the public Internet if the &obs; instance is a public
Expand All @@ -201,7 +201,7 @@
connections to the Internet as described below.
</para>
</sect3>
<sect3 xml:id="untrusted-code">
<sect3 xml:id="trust-zones-public-zone-untrusted-code">
<title>Untrusted Code</title>
<para>
All code which is used to build content is considered
Expand All @@ -215,12 +215,12 @@
</para>
</sect3>
</sect2>
<sect2 xml:id="dmz">
<sect2 xml:id="trust-zones-dmz">
<title>Demilitarized Zone (DMZ)</title>
<para>The Demilitarized Zone contains services which interact with
the public zone directly.
</para>
<sect3 xml:id="frontend">
<sect3 xml:id="trust-zones-dmz-frontend">
<title>&obs; Frontend</title>
<para>
The frontend service is the only service which provides an open port.
Expand All @@ -230,23 +230,23 @@
the source server only.
</para>
</sect3>
<sect3 xml:id="frontend-background">
<sect3 xml:id="trust-zones-dmz-frontend-background">
<title>&obs; Frontend Background Services</title>
<para>
&obs; frontend background services handle less time critical operations.
This includes services which read data from external services like bug
trackers, sending notifications or long running jobs.
</para>
</sect3>
<sect3 xml:id="stage-server">
<sect3 xml:id="trust-zones-dmz-stage-server">
<title>Stage Server</title>
<para>
The stage server is providing the public content of the &obs; backends.
The server can be publicly accessible or just an upload server to
a mirror infrastructure.
</para>
</sect3>
<sect3 xml:id="cloud-uploader">
<sect3 xml:id="trust-zones-dmz-cloud-uploader">
<title>Cloud Uploader</title>
<para>
The cloud uploader is uploading build results on user request. It reads
Expand All @@ -255,7 +255,7 @@
This is an optional service.
</para>
</sect3>
<sect3 xml:id="source-service">
<sect3 xml:id="trust-zones-dmz-source-service">
<title>Source Service Server</title>
<para>
The source service server is acting based on uploaded sources. The
Expand All @@ -266,12 +266,12 @@
</para>
</sect3>
</sect2>
<sect2 xml:id="internal-zone">
<sect2 xml:id="trust-zones-internal-zone">
<title>Internal Zone</title>
<para>The internal zone is running service which are supposed to work
without further external dependency.
</para>
<sect3 xml:id="source-server">
<sect3 xml:id="trust-zones-internal-zone-source-server">
<title>&obs; Source Server</title>
<para>
The source server coordinates changes to package and project configuration.
Expand All @@ -281,15 +281,15 @@
There can only be a single source server per OBS install.
</para>
</sect3>
<sect3 xml:id="binary-server">
<sect3 xml:id="trust-zones-internal-zone-binary-server">
<title>&obs; Binary Servers</title>
<para>
Binary Servers are hosting all content of build results. They
also prepare public repositories and deliver them to the
staging server.
</para>
</sect3>
<sect3 xml:id="external-dependencies">
<sect3 xml:id="trust-zones-internal-zone-external-dependencies">
<title>External Dependencies</title>
<para>
The internal zone has no external dependency.
Expand All @@ -300,19 +300,19 @@
</para>
</sect3>
</sect2>
<sect2 xml:id="worker-zone">
<sect2 xml:id="trust-zones-worker-zone">
<title>Worker Zone</title>
<para>The &obs; workers are running in an own isolated network.
They access only source and binary servers from internal zone.
</para>
</sect2>
<sect2 xml:id="signing-server">
<sect2 xml:id="trust-zones-signing-server">
<title>Signing Server</title>
<para>The signing server is supposed to be the most isolated service.
It is supposed to be stateless after initial setup.
Avoid to enable any remote access.
</para>
<figure xml:id="fig-obsbg-trust-zones">
<figure>
<title>Trust Zones of &obs;</title>
<mediaobject>
<imageobject>
Expand Down

0 comments on commit ca19486

Please sign in to comment.