dtApps

A dtApp is a Kubernetes CRD type that allows exposing Kubernetes services through DTaaS. This is useful when controlling Kubernetes object life cycles through some other means rather than the DTaaS API. For example, it’s possible to deploy a web application to Kubernetes with helm, and then expose the web interface to DTaaS users with a dtApp. The Authentication semantics require additional work in this case if authentication is desireable. It is not currently possible to assign Capabilities to a dtApp directly, so the DTaaS Capability system cannot help. Instead, access control needs to be handled manually either by the web application itself, or with another service that will be called with the NGINX auth_request directive.

Example

The yaml for adding a dtApp to Kubernetes looks like:

apiVersion: sid.sightlineinnovation.com/v1
kind: dtApp
metadata:
  name: myApp
serviceSelector:
  name: dummyService
spec:
  authenticationType: None

This exposes the service dummyService on port 8080 and, assuming the DTaaS instance is running at dtaas.example.org, creates the URL myApp.dtaas.example.org where it can be accessed. No authentication will be required to access it.

A more complicated example would be:

apiVersion: sid.sightlineinnovation.com/v1
kind: dtApp
metadata:
  name: myApp
serviceSelector:
  name: dummyService
  port: 8080
spec:
  authenticationType: Custom
  authenticationURL: http://authentication.example.org

In this example we’re still exposing dummyService but now explicitly sending requests to port 8080 instead of relying on the default. Authentication is enabled and being provided by http://authentication.example.org.

serviceSelector

The serviceSelector is how we can define what service to expose and how to expose it. There are two attributes that can be set are name and port. name defines the name of the service we’re exposing and port defines what port for the service we are routing requests to. The default port to redirect to is port 8080.

spec

The spec is used to define the type of authentication to apply to the new subdomain in DTaaS. The spec is composed of an authenticationType and possibly an authenticationURL depending on the value of authenticationType. authenticationType supports None, and Custom, one of which must be set.

Setting authenticationType to None results in no authentication being applied. This means anyone who can make a request to the URL will have that request redirected to the underlying service. This does not prevent any authentication implemented by the underlying service from rejecting incoming requests. This is the equivalent of setting authenticate=False during Servable creation.

Setting authenticationType to Custom requires defining an authentication service to be used to authorize the request. This URL is accessed using the nginx auth_request directive and must conform to its requirements.

Federated dtApps

If a DTaaS node is connected to a dtDomain it’s possible to configure a dtApp such that it exposes the underlying service to the other nodes in the domain. This is done using the domainSelector section. The domainSelector field is an object with a single name key. The value for name is a list of string names of domains that the app should be accessible within. At this time, a node can only be a member of one domain, and so a dtApp can only ever be accessible over one domain.

A dtApp can also be removed from a federation by removing the name of its domain from the list in the domainSelector.