Securing Orchestrated Containers with BSI Module SYS.1.6

Christoph Haar and Erik Buchmann

Hochschule f

ur Telekommunikation Leipzig, Gustav-Freytag-Str. 43-45, 04277 Leipzig, Germany

Keywords:

IT-Grundschutz, IT-Security, Container Virtualization, Kubernetes, Orchestration.

Abstract:

Orchestrated container virtualization, such as Docker/Kubernetes, is an attractive option to transfer complex IT

ecosystems into the cloud. However, this is associated with new challenges for IT security. A prominent option

to secure IT infrastructures is to use security guidelines from agencies, such as Germany’s Federal Ofﬁce for

Information Security. In this work, we analyze the module ”SYS.1.6 Container” from this agency. We want

to ﬁnd out how suitable this module is to secure a typical Kubernetes scenario. Our scenario is a classical

3-tier architecture with front end, business logic and database-back end. We show that with orchestration,

the protection needs for the entire Kubernetes cluster in terms of conﬁdentiality, integrity and availability

automatically become ”high” as soon as a sensitive data object is processed or stored in any container. Our

analysis has shown that the SYS.1.6 module is generally suitable. However, we have identiﬁed three additional

threats. Two of them could be exploited automatically, as soon as a respective vulnerability appears.

1 INTRODUCTION

In 2019, a quarter of all company data was stored

in a cloud (Joseph McKendrick, 2018). In this con-

text, container virtualization is frequently used. This

allows planning, operating and maintaining complex

applications, such as database management systems

(DBMS) in an agile and cost-efﬁcient way, which is

also compatible with DevOps approaches. A promi-

nent container virtualization is the open source project

Docker (Docker Inc., 2020b). Docker containers al-

low managing applications, such as DBMS as sepa-

rate building blocks of a large IT Infrastructure. For

example, it is possible to place a preconﬁgured op-

erating system image together with a preconﬁgured

image of a database management system in a con-

tainer. This container can be evaluated it in a test

environment, transferred to a productive system and

duplicated on several host computers if the demand

for resources increases.

In this paper, we use DBMS as our running ex-

ample. The Docker repository (Docker Inc., 2020a)

currently lists 6,238 container images with the key-

word ”database”. This includes relational DBMS,

such as Oracle, Postgres or SQL Server, and special

systems, such as Couchbase, MongoDB or MariaDB.

In addition to the operating system image and one or

more application images, a container can also contain

sensitive company data or personal information. To

manage different container instances across multiple

hosts, an orchestration like Kubernetes (The Kuber-

netes Authors, 2020) is frequently used. The orches-

tration monitors and assigns resources, such as stor-

age or computing power, controls network access and

isolates the container instances against each other. It

also allocates containers to virtual machines and vir-

tual machines to physical hosts in a data center.

Due to the orchestration, the security measures

implemented in a DBMS lose their importance as the

ﬁrst line of defense between sensitive data, users and

public networks. The DBMS cannot control the re-

sources of its tenants, if the orchestration can with-

draw resources from containers (Kanchanadevi et al.,

2019). The orchestration also controls the data ex-

change between containers, i.e., it ignores the settings

stored in the DBMS (Gao et al., 2017). Each con-

tainer imports its own DBMS instance via an image.

Typically, each DBMS instance is only responsible

for one database, and uses only one administrator and

one user account. Therefore, the isolation between

the DBMS clients is forwarded to the container iso-

lation (Mardan and Kono, 2020). Since the container

instances only exist in the main memory, persistent

data must be stored on another host. This means that

the protection needs for the managed data must be

transferred from the DBMS to the container virtual-

ization and orchestration, and consider multiple hosts

in a complex IT ecosystem.

676

Haar, C. and Buchmann, E.

Securing Orchestrated Containers with BSI Module SYS.1.6.

DOI: 10.5220/0010340406760683

In Proceedings of the 7th International Conference on Information Systems Security and Privacy (ICISSP 2021), pages 676-683

ISBN: 978-989-758-491-6

Standardized compilations of security guidelines

allow to systematically develop security concepts.

Examples are the IT-Grundschutz (BSI, 2011) from

the Federal Ofﬁce for Information Security (BSI), the

ISO 27001 certiﬁcation (BSI, 2014), or the Infor-

mation Security Practice Guides (NIST, 2020) from

the National Institute of Standards and Technology

(NIST). In this work, we focus on the IT-Grundschutz

approach from BSI. Currently, the BSI is develop-

ing the module ”SYS.1.6 Container” (BSI, 2020).

We have already shown that SYS.1.6 is applicable

to secure containers, which are executed on a single

host (Haar and Buchmann, 2019). In this work, we

use a typical database scenario to analyze the suitabil-

ity of the 2020 draft of SYS.1.6 to secure an orches-

trated container virtualization.

We have developed a protection concept accord-

ing to IT-Grundschutz for a typical Kubernetes sce-

nario (Vaughan-Nichols S., 2020). This scenario con-

sists of a DBMS with customer data, a business logic

including payment system, and a web application as a

front end. We model the information domain for our

Kubernetes system according to BSI standard 200-

2 (BSI, 2017a). Then we determine the protection

needs and analyze the elementary threats described in

the BSI module SYS.1.6 Container. Because some

data objects in the database in the information do-

main require the protection need ”high”, we will do

a risk analysis according to BSI standard 200-3 (BSI,

2017b) in a second step to identify and evaluate addi-

tional threats to our Kubernetes System.

We have observed that in an orchestrated container

virtualization system, a single data object with the

protection need ”high” for conﬁdentiality, integrity

or availability ensures that the entire system must be

assigned with this protection need. This is, because

the orchestration decides at run-time which instances

of a container are running and where. Our analy-

sis has shown that SYS.1.6 is suitable for securing

such a scenario. However, we have found three ad-

ditional threats that are not considered in SYS.1.6.

Two threats could be used to implement an automated

exploit, as soon as an attacker ﬁnds a corresponding

vulnerability. Note that SYS.1.6 from the BSI consid-

ers the same set of security risks as the ”Application

Container Security Guide” (NIST, 2017) from NIST.

Thus, our results can be transferred to the Information

Security Practice Guides.

Structure of the Work. Section 2 describes Docker,

Kubernetes and IT-Grundschutz. In Sections 3 and 4

we perform a risk analysis and compare our ﬁndings

with those from BSI. Section 5 concludes.

2 RELATED WORK

In this section, we explain the standard protec-

tion and risk analysis according to BSI, the module

SYS.1.6 (BSI, 2020) and the basics of Docker and

Kubernetes.

2.1 BSI Standard-protection

The BSI standard 200-2 (BSI, 2017a) deﬁnes six steps

to secure a typical IT system. We use these steps as

our research method.

1. The scope must be deﬁned ﬁrst. The scope is the

information domain to be protected.

2. In the structure analysis, the processes, applica-

tions, IT-Systems, infrastructures, etc. within the

scope are deﬁned as target objects.

3. The third step deﬁnes protection needs for the

business processes, the information processed and

the information technology used.

4. In the modeling step, the modules of the IT-

Grundschutz-Kompendium (BSI, 2019) are used

to identify security measures for the target objects,

depending on the protection needs.

5. The IT-Grundschutz-Check ﬁnds out if the im-

plemented security measures are sufﬁcient to ful-

ﬁll the protection needs.

6. A risk analysis must be implemented if a target

object has protection needs above normal, if if no

BSI module exists for a target object, or if a target

object is operated in an unusual way.

The risk analysis identiﬁes additional threats that

are not considered in the modules. The BSI standard

200-3 (BSI, 2017b) provides a set of questions that

help to perform such a risk analysis. These questions

should be answered by experts, employees, adminis-

trators and users for each target object:

• Which ”force majeure” threats are relevant?

• Are there organizational deﬁciencies that have an

impact on information security?

• Can the safety be compromised by human errors?

• Do technical failures result in security problems?

• Which threats can arise from external attacks?

• Is it possible for employees to willfully impair the

operation of the target object?

• Is it possible that objects outside of the informa-

tion system cause a risk?

• What information is provided by the manufac-

turer’s documentation and third parties?

Securing Orchestrated Containers with BSI Module SYS.1.6

677

Table 1: Standard-Requirement SYS.1.6.A26.

Requirement Description

SYS.1.6.A26 Service accounts in containers

The accounts used by the processes inside a container application SHOULD not have permissions

on the host that executes the container environment. If this is necessary, these permissions SHOULD

be restricted on the data that is absolutely necessary.

2.2 Module SYS.1.6: Container and

Application Container Security

In the BSI-Grundschutz-Compendium (BSI, 2019),

each module secures a speciﬁc target object. A mod-

ule contains a description of the target object, the ob-

jectives of the protection, cross-references to other

objects. The main part of each module is a descrip-

tion of speciﬁc threats for the target object, together

with a set of requirements to avoid these threats. Fi-

nally, each module lists standard security measures.

The requirements are divided into (1) basic re-

quirements that must be implemented as quickly as

possible, (2) standard requirements that should be

implemented to achieve basic protection, and (3) re-

quirements that must be implemented when there is

an increased need for protection. With pre-deﬁned

terms like SHOULD or MUST, the module points out

the importance of the requirements. Table 1 shows an

example of the requirement A26 of the SYS.1.6 mod-

ule. A26 belongs to ”standard requirements”.

To secure an orchestrated container virtualization

with Kubernetes, the BSI has published a draft of

module SYS.1.6 ”Container” (BSI, 2020). To pro-

vide an overview, we brieﬂy list the basic require-

ments (Table 2), standard requirements (Table 3) and

the requirements for increased protection (Table 4).

Table 2: Basic requirements.

ID Basic requirements

SYS.1.6.A1 Container use

SYS.1.6.A2 Separation of container apps

SYS.1.6.A3 Administration and orchestration

SYS.1.6.A4 Hardening of the host system

SYS.1.6.A5 Separation of containers

SYS.1.6.A6 Trustworthy images

SYS.1.6.A7 Hardening software in a container

SYS.1.6.A8 Persistence of logging data

SYS.1.6.A9 Persistence of user data

SYS.1.6.A10 Storing login information

SYS.1.6.A11 Administrative remote access

Note that the english translation of the module

”SYS.1.6 Container” is not available at the moment,

because the module has not been ﬁnalized yet. How-

ever, the module borrows from the ”Application Con-

tainer Security Guide” of the National Institute of

Standards and Technology (NIST) (NIST, 2017). Be-

cause of this, both approaches handle the same kinds

Table 3: Standard requirements.

ID Standard requirements

SYS.1.6.A11 Policy for operation and images

SYS.1.6.A12 One service per container

SYS.1.6.A13 Image and conf. approval

SYS.1.6.A14 Updating containers

SYS.1.6.A15 Immutability of the container

SYS.1.6.A16 Limiting container resources

SYS.1.6.A17 Mass storage for containers

SYS.1.6.A18 Securing admin. networks

SYS.1.6.A19 Separate in- and output systems

SYS.1.6 A20 Backup of conﬁguration data

SYS.1.6 A21 Unprivileged containers

SYS.1.6 A22 Securing auxiliary processes

SYS.1.6 A23 Administrative remote access

SYS.1.6 A24 Identity and auth. management

SYS.1.6 A25 Service accounts for containers

SYS.1.6 A26 Accounts in containers

SYS.1.6 A27 Monitoring containers

SYS.1.6 A28 Securing the image registry

Table 4: Requirements for high protection needs

ID Requirements for high protection

SYS.1.6.A29 Automated container auditing

SYS.1.6.A30 Private image repositories

SYS.1.6.A31 Strict access policies

SYS.1.6.A32 Host-based intrusion detection

SYS.1.6.A33 Container micro-segmentation

SYS.1.6.A34 Container high availability

SYS.1.6.A35 Encrypted data storage

SYS.1.6.A36 Encrypted communication

of risks. In particular, the basic- and standard require-

ments and requirements for a higher protection needs

from the BSI module correspond to the countermea-

sures in section four of the Application Container Se-

curity Guide. Thus, our ﬁndings can be transferred to

the Application Container Security Guide.

2.3 Orchestration and Kubernetes

Orchestration (TechnologyAdvice, 2020) allows to

efﬁciently control complex IT-Service landscapes in

the company. The most commonly used platform

for orchestrating containers is Kubernetes (Vaughan-

Nichols S., 2020). Other platforms for orchestrat-

ing containers use similar concepts, e.,g., Apache

Mesos (Foundation, 2020), AWS Fargate (Services,

2020) or Cloudify (Ltd., 2006). See (A., 2019) for a

detailed description.

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

678

Docker Engine

Docker

Daemon

Docker

Client

Linux Kernel

Server Hardware

Container 1

- Web Application (Frontend)

- Web Server

POD 1

Worker Node 1

Docker Engine

Docker

Daemon

Docker

Client

Linux Kernel

Server Hardware

Container 2

- Microservice

(Business-

logic)

POD 2

Worker Node 2

Container 3

- DBMS

(Backend)

POD 3

Client

Storage

Node

Master

Node

Linux Operating System Linux Operating System

Figure 1: Example-System Web-Shop.

Kubernetes is an open source platform developed

by Google, whose primary task is to monitor and con-

trol the resource utilization of individual containers

on the respective hosts. Kubernetes can start, shut

down or move container instances over multiple hosts

depending on the workload of the system and free re-

sources of the hosts. Furthermore, Kubernetes can

monitor the state of containers, it allows to conﬁgure

authorizations or migrate containers (Sayfan, 2018).

Kubernetes consists of several components. A

worker node is a physical host or a virtual machine

on which containers are operated. Themaster node

is the host that is responsible for controlling and

monitoring the resources on the worker nodes. The

etcd (The etcd authors, 2020) on the master node is a

key-value store for the conﬁguration data of all con-

tainers and services. The Kubectl tool transmits com-

mands for administration to the master node (Oliveira

et al., 2016). A kubelet is an execution environ-

ment for PODs on a worker node. PODs are a set

of one or more container instances that are managed

together (Sayfan, 2018) and use resources of the same

host. The system of worker and master nodes, as

well as other storage and network resources is a Ku-

bernetes cluster. Each worker node has a proxy

that forwards TCP/UDP packets to/from PODs. The

REST API server enables the user to establish com-

munication between master and worker nodes (Say-

fan, 2018). The scheduler monitors and plans indi-

vidual PODs, which is communicated via the REST

API server (Baier, 2017).

3 SECURING KUBERNETES

In this section, we describe a typical Kubernetes sce-

nario. For this scenario, we develop the security needs

of the BSI level ”Standard Protection”.

3.1 Information Domain

Szenario: A retailer stores a relational database with

data from a web shop. The data include customer

data, orders and payment transactions. The web shop

is also equipped with an Internet payment system that

securely processes payment transactions through var-

ious channels via a service provider. For this purpose,

the retailer has divided a classical 3-tier architecture

into three Docker containers, as shown in Figure 1:

The ﬁrst container contains the front end. This in-

cludes a web server with a PHP-based web applica-

tion. The second container contains the business logic

and the payment system as a set of REST-based mi-

croservices written in Java. A Postgres DBMS with

the database is housed in the third container. All

containers are managed by Kubernetes. Kubernetes

does not use further add-ons. Each host in the Kuber-

netes cluster contains a POD that can run multiple in-

stances of the containers. The Kubernetes scheduler

decides, depending on the workload, how many in-

stances of which container are executed within which

POD. Only the database is executed in a single in-

stance, so that there is no need to synchronize multi-

ple databases. The Kubernetes cluster runs in an on-

premise environment, i.e., the retailer is responsible

Securing Orchestrated Containers with BSI Module SYS.1.6

679

for the containers and the data-center infrastructure.

According to BSI standard 200-2 (BSI, 2017a),

the information domain must be modeled before the

protection needs are determined. Table 5 contains all

categories of data objects from our scenario. Table 6

contains all applications that are required to operate

the web shop. The software used is summarized in

table 7. Table 8 shows all host systems within the Ku-

bernetes cluster. All hosts belong to the same data

center (DC1). The master node (S0) and the worker

nodes (S1, S2) controlled by it are housed on their

own hosts. Instances of the containers (C1 - C3) with

web applications, microservices and DBMS run on

the worker nodes.

Table 5: Data of the Information Domain.

Nr. Data Object Description

D1 Personal Data Data from a natural per-

son

D2 Payload Data from applications

and service operations

D3 Account Data Login data and autho-

rization data

D4 Conﬁguration

Data

Data that controls the

system behavior

D5 Log Data Data on past operations

and transactions

Table 6: Applications of the Information Domain.

Nr. Descript. Data Software Con

A1 Web

App.

D1, D2,

D3, D4,

App. logic

in PHP

A2 Web

Server

D1, D2,

D4, D5

Apache C1

A3 Micro-

service

D2, D3,

D4, D5

REST ser-

vice

A4 Database D1, D2,

D3, D4,

Postgres

database

Table 7: Software of the Information Domain.

Nr. Description Data IT Sys-

tem

SSW1 Docker Soft-

ware

D4, D5 S1, S2

SSW2 Kubernetes

Software

D4, D5 S0

Since we focus on the orchestration, we have sum-

marized the hardware and the operating system under

S0 to S2 ”Host system”. In the following, we assume

that these objects are already protected according to

IT-Grundschutz.

Table 8: Host-Systems of the Information Domain.

Nr. Descript. Data Platform Loc.

S0 Host1 D1, D2,

D3, D4,

x86

Linux

DC1

S1 Host2 D1, D2,

D3, D4,

x86

Linux

DC1

S2 Host3 D1, D2,

D3, D4,

x86

Linux

DC1

3.2 Protection Needs

The aim of deﬁning protection needs is to ﬁnd out

which protective measures are appropriate for the re-

spective objects in the information system. According

to the standard 200-2 (BSI, 2017a), the BSI deﬁnes

three protection need categories ”normal”, ”high” and

”very high”. In the following we will deﬁne the pro-

tection needs for our Kubernetes cluster. We use the

protection need categories proposed by the BSI.

We start deﬁning the protection needs by deter-

mining the protection needs of the individual data ob-

jects (D1-D4), which are stored, processed and trans-

ferred between the containers within our Kubernetes

cluster. In the next step, the data protection needs

are passed on to the applications (A1-A4) that use the

corresponding data, and from there to the individual

worker nodes (S1 and S2) and the master node (S0).

This means that the protection needs of the data stored

in the database are transferred to the container with

the database application and to all other containers

that work on this database. The protection needs are

then transferred to the Kubernetes cluster and from

there to the physical hosts.

If data with different protection needs is stored in

the same Kubernetes cluster, the highest of these pro-

tection need is assigned to the entire Kubernetes clus-

ter. This results in a special case for an orchestrated

container virtualization:

The individual worker nodes are all connected to

each other via a central master node. This master node

can access all data of the individual worker nodes.

E.g. on the customer data in the database, as well as

on the conﬁguration data and the applications loaded

via image. Depending on its conﬁguration at runtime,

the orchestration controls which containers are started

in which POD.

For this reason, the protection needs of each in-

dividual worker node are passed on to the entire Ku-

bernetes cluster and ﬁnally to the entire information

domain. In addition, continuous availability of the

Kubernetes cluster is only guaranteed if at least one

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

680

worker node and the master node are operational.

Therefore, only the highest protection need with re-

gard to conﬁdentiality, integrity and availability of the

data have to be analyzed to determine the protection

needs. From there, the protection needs are passed on

to all containers, all PODs that manage these contain-

ers, and all worker nodes that execute the PODs.

This means for our application scenario:

• Conﬁdentiality. D1 and D3 store personal data,

which always have at least the protection need

”high”. The orchestration determines at runtime

on which worker node container instances with

DBMS and the other applications are executed.

For this reason, conﬁdentiality must be ”high” for

every worker node. The same applies to the mas-

ter node, as it is controls the worker nodes. This is

why the entire information system has a high need

for protection with regard to conﬁdentiality.

• Integrity. A central service in our scenario is

the processing of customer payment transactions.

Payment data (D1, D2) must not be changed with-

out authorization. Because it is also not known in

advance on which worker node the payment ser-

vice is running, the protection needs of the infor-

mation system with regard to integrity are ”high”.

• Availability. If one of the applications (A1-A4) is

discontinued, the web shop is out of service. For

this reason, the availability must be ”high” for any

target object in the entire information domain.

4 KUBERNETES THREATS

In the previous section, we have learned that the se-

curity demand for the entire system is ”high” for in-

tegrity, conﬁdentiality and availability. This is due to

the fact that the orchestration decides at run-time on

which host sensible data objects are managed. For any

risk level above ”normal”, BSI standard 200-3 (BSI,

2017b) requires us to do a risk analysis to (i) identify

and (ii) assess additional threats.

4.1 Identifying Additional Threats

We performed a risk analysis as described in Sec-

tion 2.1. Our experts were part-time students and em-

ployees of the IT-Departments of Deutsche Telekom

AG and T-Systems GmbH, with many years of pro-

fessional experience. Our experts have identiﬁed 10

different additional threats for our scenario (see Ta-

ble 9). Seven of them are identical to the threats

which we have already identiﬁed for container vir-

tualization without orchestration, i.e., we were able

to conﬁrm our previous work (Haar and Buchmann,

2019). By now, those threats are also part of the BSI

module (BSI, 2020).

Table 9: Additional Threats for the Kubernetes-System.

Identiﬁed in SYS.1.6

Vulnerabilities in images

Insecure administrative access

Orchestration with insecure tools

Container breakout

Data loss due to lack of persistence

Loss of conﬁdentiality of login information

Unauthorized modiﬁcation of conﬁguration data

Not identiﬁed in SYS.1.6

Bad planning of etcd

Compromising the nodes

Unauthorized access to the etcd

4.2 Risk Assessment

For each additional threat, the BSI standard (BSI,

2017b) requires a qualitative risk assessment to quan-

tify the potential danger. In the following, we per-

form this risk assessment for the three risks the mod-

ule SYS.1.6 does not consider so far.

The risk is the product of the frequency of occur-

rence and the extent of the damage (BSI, 2017b). We

have used a categorization of occurrences and dam-

ages, which is in line with the BSI recommendation.

A detailed categorization can be found in (Haar and

Buchmann, 2019).

Tables 10 to 12 contain our risk assessment. Each

table lists the object from the information system to

which the threat relates, the threat itself, the impaired

basic values, frequency of occurrence, extent of dam-

age, risk and an intuitive description.

We already knew from preliminary work (Haar

and Buchmann, 2019) that executing database sys-

tems in a container virtualization leads to new secu-

rity challenges. If the DBMS is operated on its own

host, the operator can directly control which database

and system rights exist, when which security patches

are imported, and when the DBMS is started or shut

down. This becomes more difﬁcult with container vir-

tualization. The orchestration increases these chal-

lenges. Due to the orchestration, a large number of

containers can be started, stopped, modiﬁed, recon-

ﬁgured or relocated at once. Therefore, the orches-

tration is an attractive target for an attacker. The

SYS.1.6 module offers a valuable support when pro-

tecting such a system. However, our risk analysis has

shown that three kubernetes-speciﬁc threats are not

included in the module. ”Compromising the nodes”

and ”Unauthorized access to the etcd” are even suit-

Securing Orchestrated Containers with BSI Module SYS.1.6

681

Table 10: Risk: Bad Planning of the etcd.

Kubernetes-System (Conﬁdentiality: high, Integrity: high, Availability: high)

Threat: Bad Planning of etcd Impaired Core Values: Availability

Frequency of Occurrence with-

out add. Measures: medium

Extent of Damage without add.

Measures: considerable

Risk without add. Mea-

sures: high

Description: A bad planning of the key-value-store, which serves as persistent storage for all data of

all clusters (etcd) can be caused by inattentive or untrained personnel. Because the etcd is the central

backup storage for the entire Kubernetes cluster, bad planning means that there is no backup available

in case of data loss due to e.g. Power outages.

Rating: A bad planning of the etcd could occur that entire memory for conﬁguration data of the Ku-

bernetes cluster is not available. In case of a system failure, access to the backup memory would not

be possible. The result would be a permanent loss of the data. Such a loss of all data would have

catastrophic consequences for business continuity. Accordingly, this risk is to be classiﬁed as high.

Table 11: Risk: Compromising the Nodes.

Kubernetes-System (Conﬁdentiality: high, Integrity: high, Availability: high)

Threat: Compromising the

Nodes

Impaired Core Values: Conﬁdentiality, Integrity, Availability

Frequency of Occurrence with-

out add. Measures: frequently

Extent of Damage without add.

Measures: considerable

Risk without add. Mea-

sures: high

Description: An attacker who gains access to one or more worker nodes could view the data processed

by the containers, manipulate them or shut down entire containers.

Rating: A compromise of the worker nodes would affect all three core values. If an attacker compro-

mises the worker node that includes a customer database, the attacker would have access to all customer

data and he would also be able to change or even delete it. Such an attack would be existence-threatening.

Table 12: Risk: Unauthorized Access to the etcd.

Kubernetes-System (Conﬁdentiality: high, Integrity: high, Availability: high)

Threat: Unauthorized Access to

the etcd

Impaired Core Values: Conﬁdentiality, Integrity, Availability

Frequency of Occurrence with-

out add. Measures: frequently

Extent of Damage without add.

Measures: considerable

Risk without add. Mea-

sures: high

Description: Unauthorized access to the etcd can cause considerable damage to all three core values.

The master node represents an attractive target for attackers, because the etcd is located in it. The etcd

represents the backup storage for the entire Kubernetes cluster. Therefore, the security of the etcd is

decisive for the conﬁdentiality, integrity or availability of all objects in the Kubernetes cluster.

Rating: Unauthorized access to the etcd would enable the attacker to view, manipulate or delete all data

in the Kubernetes cluster. Such an attack would be existence-threatening.

able for automatable attacks on the system as soon as

a corresponding vulnerability becomes known.

Furthermore, the risks described are also not in-

cluded in the NIST guideline ”Application Container

Security Guide” from which the BSI module bor-

rows. Thus, our ﬁndings from the IT-Grundschutz can

be directly transferred to the cyber security Frame-

work (NIST, 2017).

5 CONCLUSION

Orchestrated container virtualization environments

such as Kubernetes/Docker offer a ﬂexible, modern

approach to build complex applications. Contain-

ers can be quickly assembled from preconﬁgured im-

ages, and the orchestration automates the manage-

ment of large numbers of container instances across

many hosts. However, this approach brings new chal-

lenges for the protection of database applications.

In this work, we analyzed the BSI module

SYS.1.6 ”Container”, which was extended for orches-

ICISSP 2021 - 7th International Conference on Information Systems Security and Privacy

682

tration in March 2020. For this purpose, we modeled

a complex Kubernetes/Docker scenario. This sce-

nario consisted of three containers with (i) a Postgres

DBMS, (ii) the business logic and a payment system,

and (iii) a web application on an Apache web server.

For this scenario we derived a standard protection and

a risk analysis according to BSI IT-Grundschutz.

Our analysis has shown that the module is suit-

able to secure a complex 3-tier business application in

an orchestrated container environment. However, we

were able to identify three technology-independent,

additional threats that are not considered in SYS.1.6.

REFERENCES

A., C. (2019). 9 Best Kubernetes Alternatives For

DevOps Engineers. https://analyticsindiamag.com/9-

best-kubernetes-alternatives-for-devops-engineers/,

accessed Nov. 2020.

Baier, J. (2017). Getting Started with Kubernetes. Packt

Publishing.

BSI (2011). Taking advantage of opportunities – avoid-

ing risks. https://www.bsi.bund.de/EN. Bundesamt f

Sicherheit in der Informationstechnik.

BSI (2014). BSI Standards and Certiﬁcation.

https://www.bsi.bund.de/EN/Topics/ITGrundschutz/

itgrundschutz node.html. Bundesamt f

ur Sicherheit

in der Informationstechnik.

BSI (2017a). BSI-Standard 200-2: IT-Grundschutz-

Methodology. https://www.bsi.bund.de/SharedDocs/

Downloads/DE/BSI/Grundschutz/International/

bsi-standard-2002 en pdf.html. Bundesamt f

Sicherheit in der Informationstechnik.

BSI (2017b). BSI-Standard 200-3: Risk Analysis

based on IT-Grundschutz. https:// www.bsi.bund.

de/SharedDocs/ Downloads/ DE/ BSI/ Grundschutz/

International/bsi-standard-2003 en pdf.html. Bun-

desamt f

ur Sicherheit in der Informationstechnik.

BSI (2019). BSI IT-Grundschutz-Compendium Edi-

tion 2019. https:// www.bsi.bund.de/SharedDocs/

Downloads/DE/BSI/Grundschutz/International/

bsi-it-gs-comp-2019.html. Bundesamt f

ur Sicherheit

in der Informationstechnik.

BSI (2020). SYS.1.6 Container.

Docker Inc. (2020a). Docker Hub. https://hub.docker.com,

accessedNov.2020.

Docker Inc. (2020b). Docker Overview. https:

//docs.docker.com/engine/docker-overview,

accessedNov.2020.

Foundation, T. A. S. (2020). Apache Mesos.

http://mesos.apache.org/.

Gao, X., Gu, Z., Kayaalp, M., Pendarakis, D., and Wang,

H. (2017). Containerleaks: Emerging security threats

of information leakages in container clouds. In

2017 47th Annual IEEE/IFIP International Confer-

ence on Dependable Systems and Networks (DSN),

pages 237–248. IEEE.

Haar, C. and Buchmann, E. (2019). It-grundschutz f

ur die

container-virtualisierung mit dem neuen bsi-baustein

sys. 1.6. In David, K., Geihs, K., Lange, M.,

and Stumme, G., editors, INFORMATIK 2019: 50

Jahre Gesellschaft f

ur Informatik – Informatik f

Gesellschaft, pages 479–492, Bonn. Gesellschaft f

Informatik e.V.

Joseph McKendrick (2018). 2019 IOUG Databases in the

Cloud Survey. Unisphere Research.

Kanchanadevi, P., Kumar, V. A., and Kumar, G. A. (2019).

Optimal resource allocation and load balancing for a

container as a service in a cloud computing. Journal

of Critical Reviews, 7(4):2020.

Ltd., C. P. (2006). Cloudify Cutting Edge Orchestration.

https://cloudify.co/.

Mardan, A. A. A. and Kono, K. (2020). When the virtual

machine wins over the container: Dbms performance

and isolation in virtualized environments. Journal of

Information Processing, 28:369–377.

NIST (2017). Application Container Security Guide. https:

//doi.org/ 10.6028/ NIST.SP.800-190. National Insti-

tute of Standards and Technology.

NIST (2020). SP 800 series on Information Security and

Cybersecurity Practice Guides. https://csrc.nist.gov/

publications/sp800. National Institute of Standards

and Technology.

Oliveira, C., Lung, L. C., Netto, H., and Rech, L. (2016).

Evaluating raft in docker on kubernetes. In Inter-

national Conference on Systems Science, pages 123–

130. Springer.

Sayfan, G. (2018). Mastering Kubernetes: Master the art

of container management by using the power of Ku-

bernetes, 2nd Edition. Packt Publishing.

Services, A. W. (2020). AWS Fargate.

https://aws.amazon.com/fargate/.

TechnologyAdvice (2020). What is Orchestration?

https://www.webopedia.com/TERM/O/orchestration.

html,accessedNov.2020.

The etcd authors (2020). etcd. https://etcd.io/, accessed

Nov. 2020.

The Kubernetes Authors (2020). Kubernetes Overview.

https://kubernetes.io/de/docs/concepts/overview/

what-is-kubernetes/,accessedNov.2020.

Vaughan-Nichols S. (2020). Kubernetes jumps

in popularity. https://www.zdnet.com/article/

kubernetes-jumps-in-popularity/,accessedNov.2020.

Securing Orchestrated Containers with BSI Module SYS.1.6

683