This description explains the details of the STACKIT Infrastructure API based on OpenStack.

OpenStack API Documentation

The infrastructure API (OpenStack API) provides the ability to use infrastructure functions (e.g. creation of virtual machines, see Step 1: Creating a new VM)  for providing a specific, individual infrastructure for you. This makes it easy to implement the same infrastructures for different stages (e.g. development, testing, production, etc...) and synchronize them in terms of infrastructure.

STACKIT infrastructure API (Application Programmer Interface) is based on extensive OpenStack API.  The complete OpenStack API documentation for this on the part of can be viewed under 

Additional OpenStack  CLI documentation can be found under

Password policy for the OpenStack API (Keystone)

To protect access via API, passwords for using the API must meet following rules:

  • Blocking login attempts: 300 seconds after 5 failed attempts
  • Password complexity: At least one lowercase and uppercase letters and numbers.
  • Password length: At least 20 characters
  • Password age: Password must not have been used the last 13 times
  • Minimum age: The password may only be changed again after at least 1 day

Of course, it is possible to further increase the complexity of the password used and to adapt it to corporate requirements. This should be checked by the customer and taken into account in the password assignment.

Parameters for the OpenStack API

In the following, we would like to point out the necessary parameters as a source for using the OpenStack API:

#!/usr/bin/env bash
# To use an OpenStack cloud you need to authenticate against the Identity
# service named keystone, which returns a **Token** and **Service Catalog**.
# The catalog contains the endpoints for all services the user/tenant has
# access to - such as Compute, Image Service, Identity, Object Storage, Block
# Storage, and Networking (code-named nova, glance, keystone, swift,
# cinder, and neutron).
# *NOTE*: Using the 3 *Identity API* does not necessarily mean any other
# OpenStack API is version 3. For example, your cloud provider may implement
# Image API v1.1, Block Storage API v2, and Compute API v2.0. OS_AUTH_URL is
# only for the Identity API served through keystone.
export OS_AUTH_URL=
# With the addition of Keystone we have standardized on the term **project**
# as the entity that owns the resources.
export OS_PROJECT_ID=<Project-ID from your project>
export OS_PROJECT_NAME="<Name of your project>"
export OS_USER_DOMAIN_NAME="portal_mvp"
if [ -z "$OS_USER_DOMAIN_NAME" ]; then unset OS_USER_DOMAIN_NAME; fi
export OS_PROJECT_DOMAIN_ID="portal_mvp"
if [ -z "$OS_PROJECT_DOMAIN_ID" ]; then unset OS_PROJECT_DOMAIN_ID; fi
# unset v2.0 items in case set
# In addition to the owning entity (tenant), OpenStack stores the entity
# performing the action as the **user**.
export OS_USERNAME="<User Access Token Name>"
# With Keystone you pass the keystone password.
echo "Please enter your User Access Token Password for project $OS_PROJECT_NAME as user $OS_USERNAME: "
# If your configuration has multiple regions, we set that information here.
# OS_REGION_NAME is optional and only valid in certain environments.
export OS_REGION_NAME="RegionOne"
# Don't leave a blank variable, unset it if it was empty
if [ -z "$OS_REGION_NAME" ]; then unset OS_REGION_NAME; fi
export OS_INTERFACE=public
export OS_AUTH_TYPE=password

The above parameters can also be used as a basis for infrastructure automation (e.g. Terraform). You get the contents for the respective variables when you create a User Access Tokens (UATs). The instructions for creating a UAT can be found unter Step 1: Generating of User Access Tokenof User Access Token

HashiCorp Terraform-Provider for OpenStack

OpenStack provides a unified interface to manage your STACKIT infrastructure with its API. In addition, Terraform offers an OpenStack-Provider for easy integration. The official documentation for this can be found at

Restrictions for using the OpenStack API

Project management

For accounting reasons, new projects can only be created or deleted via the portal  (see Create a Project ).

Network connections between different projects

To be able to regulate cross customer network connections and thus protect client privacy, network connections across project boundaries are disabled. This is necessary to completely isolate projects without Internet access - without bypassing the isolation via connection across another project.