Namespace Onboarding

Kubernetes namespaces are a way to organize clusters into virtual sub-clusters. A namespace is created for your team in all clusters when you are onboarded to Kubernetes. This page aims to give an overview of this namespace and common resources created within it.

Namespace onboarding is performed by applying Terraform code located in terraform-aks. Details on how to add a new namespace for your team can be found in the repository README file. You can inspect all resources created during the onboarding by looking into /terraform-aks/namespaces/environments.

Namespace common resources

The following common resources are created during Namespace Onboarding

Resource Quota

The total amount of memory and CPU that is allowed to use by all containers running in a namespace is restricted to a default amount. If you exceed this amount, Kubernetes will respond with an error event telling you that creation of pods are forbidden due to exceeded quota. Read more about namespace resource quotas in the official Kubernetes docs :book:

Increasing the default amount is done by self-service in the repo terraform-aks. Locate the correct namespaces.<cluster-name>.<environment>.tf-file and update the quota for your namespace. Then create a Pull Request against the main-branch.

RBAC

Role Based Access Control is applied as a part of the Namespace Onboarding. The following RBAC is applied:

• ClusterRoleBinding giving your team read access to resources inside your namespace as well as resources in other parts of the cluster. This role is bound to the native Kubernetes 'view' role on a cluster level
• RoleBinding giving your team access to edit resources inside your namespace. This role is bound to the native Kubernetes 'edit' role on a namespace level. To enable this, Just In Time Access is required as described in Accessing from laptop

Docker credentials

Each namespace comes with a Kubernetes Docker config Secret named acr-credentials. This secret can be used to pull container images from Gjensidige's Azure Container Registry by specifying the imagePullSecrets field:

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "test-app"
spec:
  selector:
    matchLabels:
      app: "test-app"
  template:
    metadata:
      name: "test-app"
    spec:
      containers:
        - name: "test-app"
          image: "gjensidige.azurecr.io/test-app:12345"
      imagePullSecrets:
        - name: "acr-credentials"

HotTips :fire:

Learn how to build and push a container image to Azure Container Registry with GitHub Actions in this guide

Setup for Azure AD Pod Identity

Azure AD Pod Identity enables Kubernetes applications to access cloud resources securely with Azure Active Directory using User-assigned managed identity and Service Principal.

Basic configuration for Azure AD Pod Identity is created during Namespace Onboarding:

• AzureIdentity describes the Azure User Managed Identity created for your team. This identity has access to your team's resources in Azure. The User Managed Identity is created with Terraform in this repo
• AzureIdentityBinding describes the identity binding relationship between an AzureIdentity and a pod with a specific selector as part of its label

HotTips :fire:

Learn how to use Azure AD Pod Identity to access your Azure resources in this guide

ConfigMaps containing CA Bundle and JVM TrustStore

Namespaces are also mounted with ConfigMaps for Gjensidige's common CA Bundle and JVM Truststore. Both are copied from the Heimdall On-Prem application framework.

configmap-cacerts.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: "cacerts"
binaryData:
  cacerts: "..."

configmap-ca-certificates.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: "ca-certificates"
data:
  ca-certificates.crt: "..."

HotTips :fire:

Learn how to use these ConfigMaps with your Kubernetes deployment in this guide

JWT Properties and Signing Certificate

Sometimes you need properties, and a signing certificate to enable JWT in your application. For convenience, we have provided a ConfigMap suitable for most use-cases:

configmap-jwt-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: "jwt-config"
data:
  JWTConfig.properties: "..."
  gjensidige_signer.cer: "..."

HotTips :fire:

Learn how to configure JWT for Gjensidige Spring Boot applications in this guide