Skip to content

Kubernetes API

The Kubernetes API is the entrypoint to managing your Kubernetes resources. Your Welkin administrator will provide you with a kubeconfig file upon onboarding, which is required to access the API.

The following sections describe how to access the cluster in order to manage your Kubernetes resources.

Authentication and Access Control in Welkin

In order to facilitate access control and audit logging, Welkin imposes a certain way to access the Kubernetes API. The kubeconfig file provides individual access to the Kubernetes API through Dex. Normally, you should authenticate using your organizations identity provider connected to Dex, but it is also possible for your administrator to configure static usernames and passwords.

The authorization is done by the Kubernetes API based on Kubernetes role-based access controls. Your cluster administrator will grant you permissions as part of onboarding. You have administrator access to the user workload Kubernetes Namespaces by default. In order to follow the principle of least privilege, you as a user should only have sufficient access to manage resources required by your application. User access to the Kubernetes API may need to be restricted from case to case to follow the principle of least privilege.

Note

Regardless of your privilege, you will not be able to see components such as Harbor and OpenSearch via the Kubernetes API. This is in order to comply with common logging policies, which requires logging to be sent to a tamper-proof environment. The tamper-proof environment needs to be separated from the production cluster.

Usage guide

This section focuses on using the kubeconfig.

Using the kubeconfig file

The kubeconfig file can be used with kubectl by:

  • Setting and exporting the KUBECONFIG environment variable:

Setting KUBECONFIG in terminal

Authenticating to the Kubernetes API

To authenticate to the Kubernetes API, run a kubectl command. The oidc-login plugin will launch a browser where you log in to the cluster:

Dex login page

This page contains the authentication options provided by your administrator. Select your log in method and log in:

User authentication page

Once you have logged in through the browser, you are authenticated to the cluster:

Successful login

Your credentials will then be used by the Kubernetes API to make sure you are authorized. You are now logged in and can use kubectl to manage your Kubernetes resources!

Running Example

Pre-verification

Make sure you are in the right namespace on the right cluster:

kubectl get nodes
kubectl config view --minify --output 'jsonpath={..namespace}'; echo

Configure an Image Pull Secret

To start, make sure you configure the Kubernetes cluster with an image pull secret. Ideally, you should create a container registry Robot Account, which only has pull permissions and use its token.

Important

Using your own registry credentials as an image pull secret, instead of creating a robot account, is against best practices and may violate data privacy regulations.

Your registry credentials identify you and allow you to both push and pull images. A robot account should identify the Kubernetes cluster and only be allowed to pull images.

DOCKER_USER='robot$name'       # enter robot account name
DOCKER_PASSWORD=               # enter robot secret

Now create a pull secret and (optionally) use it by default in the current namespace.

# Create a pull secret
kubectl create secret docker-registry pull-secret \
    --docker-server=harbor.$DOMAIN \
    --docker-username=$DOCKER_USER \
    --docker-password=$DOCKER_PASSWORD

# Set default pull secret in current namespace
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "pull-secret"}]}'

Note

For each Kubernetes namespace, you will have to create an image pull secret and configure it to be default. Aim to have a one-to-one-to-one mapping between Kubernetes namespaces, container registry projects and robot accounts.

Deploy user demo

Example

Here is an example Helm Chart to get you started.

If you haven't done so already, clone the user demo and ensure you are in the right folder:

git clone https://github.com/elastisys/welkin/
cd welkin/user-demo

Ensure you use the right registry project and image tag, i.e., those that you pushed in the previous example:

REGISTRY_PROJECT=demo
TAG=v1

You are ready to deploy the application.

helm upgrade \
    --install \
    myapp \
    deploy/welkin-user-demo/ \
    --set image.repository=harbor.$DOMAIN/$REGISTRY_PROJECT/welkin-user-demo \
    --set image.tag=$TAG \
    --set ingress.hostname=demo.$DOMAIN

Verification

Verify that the application was deployed successfully:

kubectl get pods
# Wait until the status of your Pod is Running.

Verify that the certificate was issued successfully:

kubectl get certificate
# Wait until your certificate shows READY True.

Verify that your application is online. You may use your browser or curl:

curl --include https://demo.$DOMAIN
# First line should be HTTP/2 200

Do not expose $DOMAIN to your users.

Although your administrator will set *.$DOMAIN to point to your applications, prefer to buy a branded domain. For example, register the domain myapp.com and point it via a CNAME or ALIAS record to myapp.$DOMAIN.

Use topologySpreadConstraints if you want cross-data-center resilience

If you want your application to tolerate a whole zone (data-center) to go down, you need to add topologySpreadConstraints by uncommenting the relevant section in values.yaml.

In order for this to work, your administrator must configure the Nodes with zone labels. You can verify if this was performed correctly typing kubectl get nodes --show-labels and checking if Nodes feature the topology.kubernetes.io/zone label.

Further reading