Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This page describes the third party tools (e.g. Jeager, Docker Repository, Splunk) used for e.g. log analysis and tracing.

When hosting a BFF on the eHealth platform for either an employee or patient solution you will be given access to the following tools.

These tools will for most cases follow a naming scheme based on:

{Vendor Short Name}-{Application Short Name}/*

Deployment specified as code

The deployment and configuration is defined in a dedicated git repository for each BFF application.

The git repository is hosted on the eHealth infrastructure, and is named:

{Vendor Short Name}-{Application Short Name}/helmsman

This repository contains a values.yaml file for each environment that the application can be deployed to, containing the specific values for this environment, if any.

A deployment pipeline is connected to this repository, following the outline described in Development and deployment cycle .

Docker Image hosting

Each BFF application is given a docker repository hosted on the eHealth Platform. It is only possible and allowed to deploy images to the different environments from this docker repository.

This docker repository is not meant for all development builds, but only for images that the vendor has tested and validated internally, and that the vendor believes are ready for testing and QA.

All images in the BFF docker repository is scanned for known security problems. And when any new security problems are found it is the responsibility of the Vendor to build a new BFF image, push it, test it, and make sure it is deployed.

See Docker Base Images for requirements for the image and security risk mitigation.

Docker repository is named:

{Vendor Short Name}-{Application Short Name}/bff

Helm Chart repository

The vendor is given access to the helm chart repository hosted by the eHealth Platform.

This repository contains the only helm chart that the vendor is allowed to use to deploy the BFF on the platform. The chart should be complete enough to run any BFF, with different configuration for values, health endpoints, resource usage etc.

See Helm Charts for more info about the chart.

Kubernetes namespace

All applications on the platform is hosted on Kubernetes. To enforce separation between BFF applications and to harden the security on the platform each BFF application will have it’s own Kubernetes namespace.

  • From this namespace only communication to other specified namespaces is allowed.

    • This is at the moment only the ehealth-public namespace.

  • Likewise only communication to whitelisted services outside the eHealth Platform is allowed.

Namespace is named:

{Vendor Short Name}-{Application Short Name}

Central Logging

The vendor is given access to a central log collection where you can see any logs, audits and metrics collected from the BFF. The vendor will not have access to logs for the rest of the platform services, or from other BFF applications.

When moving up through the different environments, the access will be less and less to protect against unwanted data disclosure.

Indexes available is:

{environment}_k8s_{Vendor Short Name}-{Application Short Name}_application
{environment}_k8s_{Vendor Short Name}-{Application Short Name}_audit
{environment}_k8s_{Vendor Short Name}-{Application Short Name}_metrics

See also Logging model for logging requirements.

Jaeger tracing

In the test environment the vendor is given access to a common tracing system where a call and the response times of each involved service can be found. This is possible when all involved services has implemented the header propagation as described in Call Tracing

In production the access to tracedata will be limited.

A GUI presenting the collected data for i.e. exttest car be accessed here https://jaeger.admin.exttest.ehealth.sundhed.dk/search

  • No labels