Skip to content

Purpose and scope of this Document

This document aims to highlight the different programmatic access options and the end vision that the platform team is working towards. It serves as a reference for users, project teams, and stakeholders to understand the security and reusability considerations in accessing 'Data Products' on the platform.

Background

  • The Platform team will not have the capacity or the required domain knowledge to ensure that all 'Data Products' on the platform are designed optimally from a security and reusability perspective.
  • The KaaS Platform Team aims to give LOB Teams/projects as much self-service control and guidance as possible.
  • The team promotes long-term perspectives regarding:
    • Maintenance
    • Reuse
    • Efficient operations

In the ideal world, all accesses—both from users and systems/applications—are handled in a similar fashion, e.g., using NovoAccess to ensure review and approval of the access request by an owner, and automation to provision the permissions and associated credentials.

For users, this is quite simple, as we have standardized, predefined roles linked to entitlements in NovoAccess that can be authenticated via SSO. For 'Data Products', this is more complicated, as their requirements (scopes, resource owners, clients) are defined per use case and need to be configured ad-hoc.

SSL Enabled Protocols

Both TLS 1.3 and TLS 1.2 are supported for all dedicated clusters (dev/tst/qa/prd) in the platform across all environments. The supported cipher suites include:

TLS/SSL cipher suites

TLS 1.2

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

TLS 1.3

  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
  • TLS_CHACHA20_POLY1305_SHA256

More information can be read in the Confluent documentation.

OAuth 2.0 and Open ID Connect

The long-term vision for platform security is to use Open ID Connect (an extension of OAuth with user authentication, referred to as OIDC). In this page, we will not delve into details about the protocol (If this is gibberish to you, have a look at this OAuth 2.0 and OpenID Connect For Dummies).

While it is more complicated and requires an initial setup, the benefits of going in this direction are: - No credentials being shared and potentially stolen/misused. - No keys need to be rotated (often a manual and tedious process). - Reduced complex administration of maintaining scopes (read and write access to specific resource entities). - It is difficult to trace interactions and API key utilization.

However, due to the following limitations and constraints, KaaS is currently supporting user SSO with SAML and using service accounts with API keys for system-to-system access (service-to-service, provider-to-consumer): - Limited governance and automation within Novo Nordisk Entra AD (owners approve in Azure AD). - Limited integration and automation between KaaS and Entra AD (complex linking producers and consumers' identity pools in Confluent with Entra AD 'App Registrations'). - Limited support from some third-party or vendor-provided components (e.g., connectors, Flink).

User-generated Keys

Within Confluent Cloud (and other services), it is often possible to generate API keys (self-service) that inherit the permissions of the user account that generated them. These keys often don't have the correct scope (too many privileges) and on top of that, API keys linked to user accounts become invalid when the user exits the organization. This means that user-generated keys should never be used in production; instead, they should be owned and generated by a service account.

Current, Temporary Solution

Currently, we recommend that LOB projects/teams on the platform request that Service Accounts be created to own and generate API keys. The Service Accounts are created centrally—more details can be found here: Service Accounts.