Administration Guides

Assign

Tiles

By default, each ingress that exists will be displayed as a tile.

To customize how a tile is displayed, you need to annotate the ingress with the configuration below:

Annotation	Default	Description
kosmos-studio.athea.tech/name	ingress name	Human readable name
kosmos-studio.athea.tech/icon	empty
kosmos-studio.athea.tech/description	empty	Human short description

Hide tile

If you do not want to display application tile, you may explicitly ignore it. Use below annotation:

kosmos-studio.athea.tech/ignore: true

You can edit using default administration UI or with CLI.

kubectl annotate ingress\
    --overwrite -n kosmos-data my-app\
    kosmos-studio.athea.tech/name="My App"

Groups

In Keycloak:

• Select Groups tab from left panel.
• Create a organization group using Create group button, for example, athea, cortaix.
• Select previously created group and create a subgroup using Create group button. Matchs defined platform groups, like datascientist, admsys, developper
• For each user, assign wanted groups, form each organization (User > Groups > Join ).

Add required annotations if missing, for example to add group based access control for datapipeline patch ingress:

kubectl annotate ingress\
    --overwrite -n kosmos-data datapipeline-ui\
    kosmos-studio.athea.tech/visible-from="/athea/datascientist /cortaix/datascientist"

Projects

A project is a logical group of namespaces. To make a project, you need to label one or more namespaces with:

kubectl label namespace mynamespace1 kosmos-studio.athea.tech/project-id=drm --overwrite
kubectl label namespace mynamespace2 kosmos-studio.athea.tech/project-id=drm --overwrite

To list namespaces belonging to a project:

kubectl get ns --selector=kosmos-studio.athea.tech/project-id=drm

When a project is created, by default group matching the project-id is considered as the owner of the project. In other words, they are implicit admin of the project and have full access over it.

E.g. User belonging to group /drm will have admin rights to project-id: drm or /drm

To give access to groups:

kubectl annotate namespace drm --overwrite\
    kosmos-studio.athea.tech/access-groups="/dataing:edit,view /adminsysteme:admin /guest:view"

Datasets

Kubernetes as Backend

A dataset is composed of two Kubernetes objects: a ConfigMap and a Secret. These objects are consumed by the Datapipeline Flow interface.

To make a dataset available to the end user, you must set the following label:

kosmos-studio.athea.tech/dataset-id

For instance, create a dataset as shown below:

apiVersion: v1
kind: Secret
metadata:
  name: sampledataset
  namespace: kosmos-data
  annotations:
    # optionnaly: give access to additional groups other than the owner: drm
    kosmos-studio.athea.tech/access-groups: /squad1:view /squad2:view
  labels:
    # group owner
    kosmos-studio.athea.tech/dataset-id: drm
    kosmos-studio.athea.tech/dataset-type: s3 # optional
type: Opaque
stringData:
  preferredusername: dev@athea.tech
  username: minioadmin
  password: minioadmin
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: sampledataset
  namespace: kosmos-data
  labels:
    kosmos-studio.athea.tech/dataset-id: drm
    kosmos-studio.athea.tech/dataset-type: s3 # optional
data:
  topics: s3a://bucket1
  addr: minio.kosmos-s3.svc.cluster.local:9000

Contexts

A Context is a group of shared key-value pairs accessible by a group of users.

Contexts are protected through namespace isolation and can have additional enforcement using annotations.

To create a Context:

kubectl apply -n drm -f- <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: sharedcontext
  annotations:
    kosmos-studio.athea.tech/access-groups: /squad1:view /squad2:view
  labels:
    kosmos-studio.athea.tech/context-id: dev
type: Opaque
stringData:
  s3Endpoint: minio.kosmos-s3.svc.cluster.local:9000
  s3Username: minioadmin
  s3Password: minioadmin
EOF

Users who have access to the drm namespace and belong to either the /squad1 or /squad2 group can use this context in their deployments.

When deploying using Kosmos-Studio, you can reference a given context as follow:

# values.yaml
# drm=secretNamespace
# sharedcontext=secretName
# dev=contextId
meta: >
  SET s3_endpoint='{{ .drm.sharedcontext.dev.s3Endpoint }}';
  SET s3_region='us-east-1';
  SET s3_access_key_id='{{ .drm.sharedcontext.dev.s3Username }}';
  SET s3_secret_access_key='{{ .drm.sharedcontext.dev.s3Password }}';
  SET s3_url_style='path';
  SET s3_use_ssl = false;
query: >
  CREATE TABLE data AS SELECT * FROM read_ndjson_auto('s3://bucket1/file.ndjson');
  COPY data TO 's3://bucket1/copied_file.csv' (FORMAT 'csv');

Healthz

Make the S3 service discoverable for healthiness and as context variable:

Special scenario

Illustration of an operator driven deployment (Minio), where drift on deployed resources are captured and rollback to match applied CR instance. You need to update the CR that enable the deployment of such resource:

kubectl patch tenant s3-cluster \
  -n kosmos-s3 \
  --type='merge' \
  -p '{"spec":{"serviceMetadata":{"minioServiceAnnotations":{"kosmos-studio.athea.tech/access-groups":"/dataing:edit,view /adminsysteme:admin /guest:view","kosmos-studio.athea.tech/health-check":"http://minio.kosmos-s3.svc.cluster.local/minio/health/ready"},"minioServiceLabels":{"kosmos-studio.athea.tech/application-id":"s3-cluster"}}}}'

In most cases, you only need to label and annotate as follows:

Label

kubectl label svc s3-cluster-hl\
  --namespace kosmos-s3 --overwrite\
  kosmos-studio.athea.tech/application-id=s3-cluster-hl

Then, annotate

# internal service
kubectl annotate svc s3-cluster-hl \
  --namespace kosmos-s3 --overwrite \
  kosmos-studio.athea.tech/health-check="http://s3-cluster-hl.kosmos-s3.svc.cluster.local:9000/minio/health/ready" \
  kosmos-studio.athea.tech/access-groups="/dataing:edit,view /adminsysteme:admin /guest:view"

# public endpoint
kubectl annotate svc s3-cluster-hl \
  --namespace kosmos-s3 --overwrite \
  kosmos-studio.athea.tech/health-check="https://s3-api-admin.kosmos.athea/minio/health/ready" \
  kosmos-studio.athea.tech/access-groups="/dataing:edit,view /adminsysteme:admin /guest:view"

Superuser

Default groups

User belonging to one of the listed groups below are considered as Superuser:

• superadmin
• adminsysteme
• admininfra
• adminsecurite

Default User

Upon deployment, a superadmin user is created: kstudioadmin.

This user can only authenticate using Basic Authentication.

# get password
kubectl get secret kosmos-studio-initial-admin -n kosmos-data -oyaml| yq .data.password

Customizations

Hub Icon

To customize your Application icon, upload an image to the sys.kosmos-studio bucket under the path:

# icon resolution from bucket has a fallback behavior
icons/hub/(.metadata.annotations.kosmos-studio.athea.tech/name)/icon.(ext) # weight: 3
icons/hub/(.metadata.helm.sh/release-name)/icon.(ext) # weight: 2
icons/hub/(.metadata.name)/icon.(ext) # weight: 1

Supported extensions are: .svg, .png, .jpeg, and .gif.

Store Icon

To customize your Helm Chart icon, upload an image to the sys.kosmos-studio bucket under the path:

icons/store/(chart_name)/icon.(ext)

Supported extensions are: .svg, .png, .jpeg, and .gif.

Policies enforcement

Buckets - Direct

When kosmos-studio is deployed under this mode, the PBAC configuration of your S3 cluster is enforced for all users authenticated via SSO.

The required group attribute for kosmos-studio Buckets feature is derived through the standard token exchange mechanism.

Buckets - S3Guard / DCS

When kosmos-studio is deployed under this mode, the S3Guard default policies are enforced:

Public Policy

This policy is required for uploads. By default, it binds the uploaded file to public.

If you are in DCS mode and the file complies with STANAG 4774/4778, your file attributes (BDO) will be merged on top of the specified uploaded attributes.

This means that the policyidentifier found in your BDO will takes priority.

{
    "id": "public",
    "namespace": "kosmos",
    "tenantId": "kosmos",
    "actions": []
}

Self Policy

This policy is used internally.

Files written by Kosmos Studio will typically apply the self policy, making the file accessible only to its owner.

{
    "id": "self",
    "namespace": "kosmos",
    "tenantId": "kosmos",
    "actions": [
        {
            "type": "filter",
            "predicate": "@data.sub == @identity.claim.sub"
        }
    ]
}