Using the Kubernetes Connector
Introduction
Everyone who requests configuration data from ConfigSeeder needs credentials granting access to the requested data. This applies to users (which access ConfigSeeder with a SAML or OIDC token) but also to applications that require an API Key. Of course, these API Keys can be provided manually. If you only run a few applications, this is quite manageable. But if you run more applications, however, manually creating API Keys can become cumbersome.
If you run your applications in one or more Kubernetes clusters, you don’t just need API Keys granting access to ConfigSeeder. In addition, your applications probably like to be configured with Kubernetes objects like ConfigMaps and Secrets. The Kubernetes Connector can not only provide Secrets that contain API Keys but also manage the ConfigMaps and Secrets required by your applications.
Suggested Setup
As described in the introduction, the Kubernetes Connector can provide configuration data and ConfigSeeder API Keys directly into a Kubernetes Cluster. The Connector stores this data in the form of ConfigMaps and Secrets.
There are several ways to use the Kubernetes Connector. Firstly, we recommend using dedicated ‘Infrastructure’ Kubernetes Connectors to manage all the API Keys needed by other applications to access the ConfigSeeder.
Secondly, we recommend using another Kubernetes Connector per application and environment.
These Connectors are responsible to manage the ConfigMaps and Secrets used by one application. We recommend this setup because it allows you to combine the installation or update of an application with the execution of the responsible Kubernetes Connector.
This leads to the setup as shown in the architecture sketches below.
Setup dedicated Infrastructure Kubernetes Connectors for providing all API Keys
As described in the introduction, every application accessing the ConfigSeeder needs an API Key that grants the required privileges. These API Keys should be managed by the Infrastructure Kubernetes Connector. In other words, the Infrastructure Kubernetes Connectors should have the only role to create these API Keys. It stores and manages the ConfigSeeder API Keys in the form of Kubernetes Secrets and can periodically check all created API Keys and replace them if required.
One Infrastructure Kubernetes Connector can only manage the API Key Secrets for one environment. Because of this limitation, you need to set up one Infrastructure Kubernetes Connector per managed environment.
ConfigSeeder Access Permissions
Of course, the Infrastructure Kubernetes Connectors also requires an API Key for accessing the ConfigSeeder. This API Key must be of type Kubernetes Connector and created and managed manually. There are two ways to enable this API Key:
- If you want to manage only a few applications with Kubernetes Connector, you can create an API Key with permissions to exactly the right configuration groups and environments.
- If you need to manage API Keys with Kubernetes Connectors for a lot of applications and environments, it is probably sensible to just create an API Key with permissions for all environments and configuration groups. This is probably a more realistic scenario.
Kubernetes Access Permissions
The Infrastructure Kubernetes Connectors requires the following Kubernetes access permissions:
- Manage ConfigMaps for managing the State
- Manage Secrets in all relevant Namespaces (see Architecture Sketch)
- Permissions to manage ConfigMaps in the Namespace of all the applications are not required.
It is easiest to run the Infrastructure Kubernetes Connectors as Kubernetes CronJobs.
See our Blog Article Using the Kubernetes Connector with Helm 3, Part 1 for setting up Infrastructure Kubernetes Connectors.
Run a Kubernetes Connector for every Application and Environment
For every application and environment, one Kubernetes Connector is responsible to create and manage all required Secrets and ConfigMaps.
These Kubernetes Connectors are run as Jobs. This allows you to control exactly when a Connector should be executed. If you use Helm to install applications to Kubernetes, you can use a pre-* Hook to run the Kubernetes Connector before Helm installs or upgrades the application.
ConfigSeeder Access Permissions
The API Key required to access the ConfigSeeder is provided by the Infrastructure Kubernetes Connector.
Kubernetes Access Permissions
The Kubernetes Connector requires permissions to
- Manage ConfigMaps for managing the State
- Manage ConfigMaps and Secrets in its Namespace.
Use the OS Connector as an Init Container
If an application requires Configfiles which can’t be provided with ConfigMaps and Secrets, the OS Connector can be used as an Init Container.
ConfigSeeder Access Permissions
The API Key required to access the ConfigSeeder is provided by the Infrastructure Kubernetes Connector.
Kubernetes Access Permissions
The OS Connector doesn’t access the Kubernetes API. Therefore the OS Connector doesn’t need Kubernetes access permissions.
Conclusion
As described in the introduction, every application that accesses the ConfigSeeder needs an API Key that grants access to the data. In addition, your applications need configuration data in the form of ConfigMaps and Secrets. You can of course provide this information manually. However, when the number of applications increases, the manual administration of the ConfigMaps and Secrets becomes tedious. Therefore, we suggest using the Kubernetes Connector to reduce the amount of manual work involved in operating your applications.
And to sum up, we recommend the following setup when using the Kubernetes Connector:
- Setup dedicated Kubernetes Connectors to create and manage all the ConfigSeeder API Keys
- For every application and environment, a Kubernetes Connector manages the required ConfigMaps and Secrets
- Sometimes an application requires a configuration that can’t be created with ConfigMaps and Secrets. In this case, you can use the OS Connector as an Init Container
If your scenario includes more then one Kubernetes Cluster the recommended setup is still valid. Because in this case, you just have to use the Context-Attribute to differentiate the Clusters from each other.
- Setup Infrastructure Kubernetes Connectors per Kubernetes Cluster (one for each environment relevant in the Cluster)
- Differentiate the Configuration for the different Clusters with the Context-Attribute
Alternatives
It is also possible to configure the Kubernetes Connector so it manages its own API Key. See our Blog article Set up the Kubernetes Connector with a self-managed API Key for more details.
Contact us
If you are unsure about the setup you should use, please don’t hesitate to contact us using the Contact Form.