Briefly describe the feature

• As a paralus user, I would like to set an auto-generated password during installation thus avoid admin to reset the password after installation
• As an admin, when I first login I would like to reset by password before logging in.
• Applicable while creating new users via dashboard, cli

What problem does this feature solve? Please link any relevant documentation or Issues

• Improves paralus usage for new users

Briefly describe the feature

Add few more points where we audit changes

• Download Kubeconfig
• API keys generate
• Download CLI config

What problem does this feature solve? Please link any relevant documentation or Issues

As of now the above mentioned places are not being logged. Having these also logged gives more visibility.

(optional) What is your current workaround?

None

Expected vs actual behavior

• after paralus installation we should be able access http://console.paralus.local. But its not loading. Im using M1 Mac Air system.

Steps to reproduce the bug

1. Follow this blog on M1 Mac.
2. once installation is completed try to access http://console.paralus.local

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

APP VERSION
v0.1.3

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• kubectl version --output=yaml

clientVersion:
buildDate: "2021-12-16T08:38:33Z"
compiler: gc
gitCommit: 5c99e2ac2ff9a3c549d9ca665e7bc05a3e18f07e
gitTreeState: clean
gitVersion: v1.22.5
goVersion: go1.16.12
major: "1"
minor: "22"
platform: darwin/arm64
serverVersion:
buildDate: "2022-05-19T15:42:59Z"
compiler: gc
gitCommit: 4ce5a8954017644c5420bae81d72b09b735c21f0
gitTreeState: clean
gitVersion: v1.24.0
goVersion: go1.18.1
major: "1"
minor: "24"
platform: linux/arm64

WARNING: version difference between client (1.22) and server (1.24) exceeds the supported minor version skew of +/-1

• helm version
  version.BuildInfo{Version:"v3.9.4", GitCommit:"dbc6d8e20fe1d58d50e6ed30f09a04a77e4c68db", GitTreeState:"clean", GoVersion:"go1.19"}

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behaviour

• When trying to assign namespace to a role I get error No special char. allowed & length between 4-64 characters. if namespace has any type of special character. This produces issues as namespaces can have - character in them
• Expected to be able to give read only namespace role to namespace pr-test

Steps to reproduce the bug

1. Install Paralus
2. Go into Settings -> Groups -> Projects -> choose Namespace Read Only role -> in namespace part type in pr-test
3. You will get an error No special char. allowed & length between 4-64 characters.

Are you using the latest version of the project?

• chart ztka-0.2.0
• app version v0.1.9

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

Environment is running on Google Cloud GKE
kubectl version --outpout=yaml
clientVersion: buildDate: "2022-11-09T13:28:30Z" compiler: gc gitCommit: 872a965c6c6526caa949f0c6ac028ef7aff3fb78 gitTreeState: clean gitVersion: v1.25.4 goVersion: go1.19.3 major: "1" minor: "25" platform: darwin/arm64 kustomizeVersion: v4.5.7 serverVersion: buildDate: "2022-10-26T09:25:23Z" compiler: gc gitCommit: 900b919b3b8275ecb9f70a489a318b5b08a4ab9c gitTreeState: clean gitVersion: v1.23.13-gke.900 goVersion: go1.17.13b7 major: "1" minor: "23" platform: linux/amd64

helm version
version.BuildInfo{Version:"v3.8.0", GitCommit:"d14138609b01886f544b2025f5000351c9eb092e", GitTreeState:"clean", GoVersion:"go1.17.6"}

WARNING: version difference between client (1.25) and server (1.23) exceeds the supported minor version skew of +/-1`

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behavior

• Last access time should be shown per user depending on when the last logged in Paralus application

Steps to reproduce the bug

1. Go to users list screen from main menu

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Reproducible anywhere

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• Need to enhance the user endpoint and fetch the last access information from kratos.

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Briefly describe the feature

• Add new organization and partner basic information api which will be non-restricted and public
• Only organization, partner id and name information will be fetched
• Will be used in dashboard to load before user login
• Impact to CLI to be checked
• Remove the existing mandatory permissions validation for organization / partner
• Skip only kubectl related permissions from authz.

What problem does this feature solve? Please link any relevant documentation or Issues

• It removes the dependency for all custom roles to have organization, partner read only permissions. Thus enabling creating custom roles with just hand-picked api permissions depending on the use case.

(optional) What is your current workaround?

• Currently, while creating custom roles organization, partner read permissions are made mandatory so that users / systems can use those custom roles

Describe the issue you're facing

Kratos now parse all claims into raw_claims. OIDC provider that returns groups information in claims can be directly mapped to groups in Paralus.
OIDC providers mapper files: https://github.com/paralus/paralus/tree/main/_kratos/oidc-mappers

Paralus looks like a sophisticated piece of software, I am looking into ways on how to connect all our clusters with different providers to our OIDC IDP. I see all the features of Paralus, but many are IDP related, so what will I miss when using kubelogin with a powerful IDP

Expected vs actual behavior

Expected: pass buf lint

Steps to reproduce the bug

1. Run buf lint

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Log: buf-lint.log

Most of them are naming convention details

Briefly describe the feature

• Add a new audit log event (user.login.success) whenever a user logs in to Paralus

What problem does this feature solve? Please link any relevant documentation or Issues

• As of now user login is not being logged. Having this gives more visibility.

(optional) What is your current workaround?

• NONE

Briefly describe the feature

Add support for allowing DSN string for db connection.

What problem does this feature solve? Please link any relevant documentation or Issues

Currently Paralus accepts different database values like username, password, address etc. Adding DSN over these values makes configuration easy and reduce the number of variables required.

(optional) What is your current workaround?

Provide all database variables dbUser, dbPassword, dbAddr, dbName

If user logged in using SSO provider. Later any change in the groups (or any other data like user name) at provider side, won't reflect back in our system.

ORY Kratos currently has ory/kratos#2326 (comment).

Briefly describe the feature

Currently the user has to provide/create a yaml file during installation with custom values based on their requirement. Paralus will be deployed with those values. Further, there are different yaml files for different environments - EKS, AKS, GCP etc. so the user needs to supply the correct yaml file to correctly configure Paralus.

The idea is to have an interactive installation of Paralus where the user is asked for inputs for the configurable values and doesn't have to deal with yaml files at all.

For Eg. ask the following questions during installation:

• Are you deploying Paralus for testing or production?
• Provide a domain name to use for Paralus (if left blank, the default value will be used)
• Provide the admin user email id (if left blank, the default value will be used)
• Provide the organization name (if left blank, the default value will be used)

What problem does this feature solve? Please link any relevant documentation or Issues

Improves the user experience and makes it less complex. Currently the user needs to supply a specific yaml file or create a different one to install Paralus. With this interactive installation, user no more deals with updating values in yaml file which now will be taken care of by Paralus.

Fetch latest release from Github API and provide to the frontend for direct download.

Briefly describe the feature

• As a user, I would like to configure Paralus with traefik ingress and make it work.

What problem does this feature solve? Please link any relevant documentation or Issues

• Currently while trying to configure ingress with traefik, there is some issue with web kubectl reported.

ztka {"level":"info","ts":"2022-09-09T14:32:13.013Z","caller":"debug/handler.go:236","msg":"unable to create completer","error":"Get "[https://dae160f0-4fab-4702-b1b3-dc3b2d23d5d5.user.app.metisint.zoo:443/api/v1/namespaces](https://dae160f0-4fab-4702-b1b3-dc3b2d23d5d5.user.app.metisint.zoo/api/v1/namespaces%5C)": x509: certificate signed by unknown authority"}

(optional) What is your current workaround?

• Use the recommended contour ingress

Expected vs actual behavior

The password reset url is incorrect after upgrading the domain name. It still shows console.paralus.local though the domain was updated to 'paralusdemo.com`

However, it gives the correct URL when I try to get the reset url using the Password reset method (screenshot attached)

Steps to reproduce the bug

1. Install Paralus as 1-click app on Digital Ocean Marketplace
2. Upgrade the installation by setting the domain name using the following command:
   helm upgrade paralus paralus/ztka -n paralus --values https://raw.githubusercontent.com/paralus/helm-charts/main/examples/values.dev-generic.yaml --set fqdn.domain="yourdomain.com"
3. Post installation, use the generated code to fetch the password reset url
   kubectl logs -f --namespace paralus $(kubectl get pods --namespace paralus -l app.kubernetes.io/name='paralus' -o jsonpath='{ .items[0].metadata.name }') initialize | grep 'Org Admin signup URL:'

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

Digital Ocean 1-Click Setup

Screenshot

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

• While editing the project (by clicking on settings icon in project card from dashboard), in auth/v3/partner/partner0/organization/org0/project/freshproj api, we are getting the deleted namespaces as well in spec.projectNamespaceRole.

• Also, we aren’t the namespaces with spec.userRoles in the same project info api.

• Also, in we are getting the roles which have been deleted/unchecked previously.

• we might need to change the edit project api accordingly to manage namespace & role changes for user association

Need an architecture diagram

• Depicting the various components involved in the setup
• Interactions happening between the components
• Different touchpoints
• Protocols being used

Why is this needed?

• Helps new developers to get started with confidence
• Helps security team in evaluating the tool from security perspective
• SRE/DevOps folks gets the picture of the whole setup

The documentation is terrible for leveraging the paralus APIs. The endpoint link redirects one to the github page which has no information other than swagger JSONs. I had to examine network connections to even see what APIs are called, and even then I can't figure out how to authenticate through the APIs. I needs much better documentation so I don't have to hunt through the code.

Create a ROADMAP.md file in this repo with a list of features and/or fixes we plan to implement in the future.

Expected vs actual behavior

Expected: As a user who does not have aggregated associated cluster.write permission, I should not be able to create / delete new cluste
Actual: As a project read only user ( without cluster.write ) - I am able to create / delete new cluster for import

Steps to reproduce the bug

1. Create a new user, associate project read only role for a project. ( or any custom role without cluster.write )
2. Login with above user and try to create / delete a cluster for import
3. You will see that we can create a cluster

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes, v0.1.9

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Applicable to all

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• Need to check authorization checks

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Briefly describe the feature

Currently there are different entrypoints for doing different paralus actions, such as Paralus initialization, db migration and starting paralus server. All of these can be combined into single tool with different sub-commands for each operation to user need to perform.

What problem does this feature solve? Please link any relevant documentation or Issues

Make it more easy to run.

(optional) What is your current workaround?

Currently we need to remember and run following command for different Paralus actions:

# Start Paralus core
go run main.go

# To perform Paralus initialization
go run scripts/initialize/main.go

# Start the Kratos providers synchronizer
go run scripts/kratos/providers_sync.go

# Paralus db migration
migrate -path=persistence/migrations/admindb -database $DSN up

If we do all these using single binary then commands will be something like:

# Start Paralus core
./paralus serve

# To perform Paralus initialization
./paralus init

# Start the Kratos providers synchronizer
./paralus sync oidc-providers

# Paralus db migration
./paralus migrate

Briefly describe the feature

• Add auth for mutually verifying authenticity of requests from sentry bootstrapping, kratos, prompt for certain open endpoints currently excluded for authz
  "/paralus.dev.sentry.rpc.BootstrapService/GetBootstrapAgentTemplate"
  "/paralus.dev.sentry.rpc.BootstrapService/RegisterBootstrapAgent"
  "/paralus.dev.sentry.rpc.KubeConfigService/GetForClusterWebSession"
  "/paralus.dev.rpc.auth.v3.AuthService/IsRequestAllowed"
  "/paralus.dev.rpc.user.v3.UserService/AuditLogWebhook"

What problem does this feature solve? Please link any relevant documentation or Issues

• Enforces zero trust principles

Briefly describe the feature

As of now, we for audit logs like project.updated.success, we are only storing just the id and the name of the changed project. We had a suggestion to add in more information on what exactly got updated. It would be useful to get more info available in these.

(optional) What is your current workaround?

None

We need to have a consistent way in which we return errors.

• Create custom error types?
• Common error codes across modules
• Easier to convert to appropriate grpc or REST errors

Design still being finalized

Expected vs actual behavior

Expected

• helm dependency update should download all dependent charts defined

Actual

• Fails with below error
  Error: can't get a valid version for repositories postgresql, contour. Try changing the version constraint in Chart.yaml

Steps to reproduce the bug

1. clean up any chart dependencies and run helm dependency update

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Applicable to all

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• Seems like bitnami has moved around a few helm versions
  bitnami/charts#10539
  bitnami/charts#10545

Currently you can overcome this by below

helm repo add bitnami-full-index https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami

update postgres repository in Chart.yaml

update contour repository in Chart.yaml

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behavior

• Expected - User should be able to successfully edit a namespaced scope custom role, also in case of failure look at the rewording the error message displayed
• Actual - User is unable to edit a namespaced scope custom role, and below is the error message

Steps to reproduce the bug

1. Go to menu -> roles, click on create a new role
2. Select namespace scope and provide a role name e.g. "DEV_NS_ADMINS"
3. Select below permissions
   i) cluster.read
   ii) kubectl.namespace.read
   iiI) kubectl.namespace.write

4. Click on save and exit -> custom role should be successfully created
5. Click on the created role to edit, remove cluster.read permission and hit save and exit which throws above error

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes, v0.1.0

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Applicable to all

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Briefly describe the feature

• Set the user context to one of the associated namespaces for namespaced roles. Currently it is set to default and the user has to explicitly mention namespaces in all the commands.
• If only one namespace is associated then user context should be defaulted to that namespace.
• If multiple namespaces, set the user context to one of the associated namespaces

What problem does this feature solve? Please link any relevant documentation or Issues

• Ability to avoid providing namespaces for all commands

(optional) What is your current workaround?

• kubectl config set-context --current --namespace=namespace-user-has-access-to

Briefly describe the feature

• Multi Factor Authentication: Make Paralus more robust and secured by implementing multi factor authentication for users.
• Explore Ory Kratos MFA Abilities

What problem does this feature solve? Please link any relevant documentation or Issues

• It gives an extra layer of security.

What is your current workaround?

• Use Open ID Connect with other major providers like google, github and use their two-auth process to enable access to Paralus.

Briefly describe the feature

• Add the ability to configure the SA account lifetime

What problem does this feature solve? Please link any relevant documentation or Issues

(optional) What is your current workaround?

ks logs -n paralus pod/paralus-689bb79dc4-zzf7t kratos-automigrate

time=2022-11-17T13:53:12Z level=info msg=No tracer configured - skipping tracing setup audience=application service_name=Ory Kratos service_version=v0.8.0-alpha.3
time=2022-11-17T13:53:12Z level=warning msg=Migrator: unable to dump schema audience=application error=map[message:exec: "pg_dump": executable file not found in $PATH] service_name=Ory Kratos service_version=v0.8.0-alpha.3
Successfully applied SQL migrations!
time=2022-11-17T13:53:12Z level=warning msg=Migrator: unable to dump schema audience=application error=map[message:exec: "pg_dump": executable file not found in $PATH] service_name=Ory Kratos service_version=v0.8.0-alpha.3

ks logs -n paralus  pod/paralus-689bb79dc4-zzf7t  migrate-admindb

error: Dirty database version 1. Fix and force version.

paralus=# SELECT * FROM schema_migrations;
version | dirty
---------+-------
1 | t
(1 row)

kubectl logs -f --namespace paralus $(kubectl get pods --namespace paralus -l [app.kubernetes.io/name='paralus]
(http://app.kubernetes.io/name='paralus)' -o jsonpath='{ .items[0].[metadata.name](http://metadata.name/) }') initialize | grep 'Org Admin signup URL:'

Error from server (BadRequest): container "initialize" in pod "paralus-6fb4c85d7c-s79xb" is waiting to start: PodInitializing

Any help please?

Expected vs actual behavior

• Expectation is that a namespace provided while associating a namespace role should be available in target cluster and Paralus should not create a namespace if it already exists.
• Current behaviour creates a namespace in target cluster if not already present.

Steps to reproduce the bug

1. Assign a namespace related role to a user and provide a namespace name that does not exist in target cluster
2. verify kubectl get ns in target cluster - namespace should not exist
3. Perform web kubectl from Paralus and you can now see that namespace is created.

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes, v0.1.0

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Impacts all environments

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• Code to check if namespace exists and create if not needs to be removed from relay and paralus sentry package.

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Briefly describe the feature

• Ability to provide fine grained access to individual resources like a workloads, pods, services etc.

What problem does this feature solve? Please link any relevant documentation or Issues

• https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Describe the feature you are requesting

• Ability to choose paralus as an addon from eks blueprints
  ref: eks blueprints

Briefly describe the feature

• Need for a cross arch / platform docker image to be built

What problem does this feature solve? Please link any relevant documentation or Issues

• Currently it builds only linux/amd64 based images. Solves lot of compatibility issues.

ES is pretty heavy and is only used for audit-logs. Would be much better if we switch to PG by default for audit logs, but probably retain an option to use ES as well. This would be much more useful in POC environments.

ref: https://www.elastic.co/guide/en/beats/filebeat/master/filebeat-module-postgresql.html

Briefly describe the feature

• If a user gets access to the container using kubectl exec -it pod -- bash, we should be knowing what all the changes user is doing.

• a good idea is to record the session, this has been done by the teleport project:

What problem does this feature solve? Please link any relevant documentation or Issues

• if a malicious user edit some files inside a container, we can review the changes in the audit sessions.

Describe the request

• Currently GH actions uses a user's account to build and publish images, change this to use a build specific account

reference: https://aws.amazon.com/marketplace/partners/management-tour

Getting the following error if we regenerate buf files:

# github.com/RafaySystems/rcloud-base/proto/types/controller
Error: proto/types/controller/init.go:20:25: cannot use &Task{} (type *Task) as type "k8s.io/apimachinery/pkg/runtime".Object in argument to SchemeBuilder.Register:
	*Task does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/init.go:20:34: cannot use &TaskList{} (type *TaskList) as type "k8s.io/apimachinery/pkg/runtime".Object in argument to SchemeBuilder.Register:
	*TaskList does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/init.go:21:25: cannot use &Tasklet{} (type *Tasklet) as type "k8s.io/apimachinery/pkg/runtime".Object in argument to SchemeBuilder.Register:
	*Tasklet does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/init.go:21:37: cannot use &TaskletList{} (type *TaskletList) as type "k8s.io/apimachinery/pkg/runtime".Object in argument to SchemeBuilder.Register:
	*TaskletList does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/init.go:22:25: cannot use &Namespace{} (type *Namespace) as type "k8s.io/apimachinery/pkg/runtime".Object in argument to SchemeBuilder.Register:
	*Namespace does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/init.go:22:39: cannot use &NamespaceList{} (type *NamespaceList) as type "k8s.io/apimachinery/pkg/runtime".Object in argument to SchemeBuilder.Register:
	*NamespaceList does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/zz_generated.deepcopy.go:25:29: cannot use &out.ObjectMeta (type **"k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta) as type *"k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta in argument to in.ObjectMeta.DeepCopyInto
Error: proto/types/controller/zz_generated.deepcopy.go:51:3: cannot use c (type *Namespace) as type "k8s.io/apimachinery/pkg/runtime".Object in return argument:
	*Namespace does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/zz_generated.deepcopy.go:91:27: cannot use &out.ListMeta (type **"k8s.io/apimachinery/pkg/apis/meta/v1".ListMeta) as type *"k8s.io/apimachinery/pkg/apis/meta/v1".ListMeta in argument to in.ListMeta.DeepCopyInto
Error: proto/types/controller/zz_generated.deepcopy.go:118:3: cannot use c (type *NamespaceList) as type "k8s.io/apimachinery/pkg/runtime".Object in return argument:
	*NamespaceList does not implement "k8s.io/apimachinery/pkg/runtime".Object (missing GetObjectKind method)
Error: proto/types/controller/zz_generated.deepcopy.go:118:3: too many errors
FAIL	github.com/RafaySystems/rcloud-base/pkg/service [build failed]
FAIL
Error: Process completed with exit code 2.

Expected vs actual behavior

• During one of the cluster update flows project id is recoded as part of auditlogs

Steps to reproduce the bug

1. Install paralus, create an imported cluster, perform kubectl and few actions on it, then delete the cluster.
2. Check the audit logs, we can see in one of the cluster update audit entry project id is recorded instead of name

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• Yes

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

• Change the repo name
• Changes to go.mod
• Changes to buf new repo
• Changes to proto files
• Changes to all files with Rafay
• Rafay Systems - certificate auth - to be changed to Paralus
• Rafay-salt reference to be cleaned up ..
• CI / CD needs to be changed
• Readme's, contributing docs, issue, features templates ..
• Governance related docs - to be checked
• Any update to copyright year and owner information in all Files / Licences if available

Briefly describe the feature

• Make swagger ui available for below
  Partner
  Organization
  Project
  User
  Group
  Role
  Role Permission
  Kubectl Setting
  OIDC Provider
  Audit Log

What problem does this feature solve? Please link any relevant documentation or Issues

• Makes it easy for developers wanting to interface with core component

Briefly describe the feature

• Ability to filter audit logs based on cluster user has access to.

What problem does this feature solve? Please link any relevant documentation or Issues

• Usability and ease of viewing audit logs for a particular cluster.

• Combine init containers in base
• Use FROM scratch for golang binaries
• https://github.com/docker-slim/docker-slim
• Use .dockerignore

• Explore using https://github.com/wagoodman/dive

Expected vs actual behavior

• Relay agent should be be successfully deployed when downloaded bootstrap is applied on target cluster

Steps to reproduce the bug

1. Click on import cluster, provide a name and click on next
2. Download the bootstrap yaml and apply that on any machine with arm64 arch ( in this instance M1 Mac )
3. You can see that relay agent does not get scheduled by kubernetes scheduler - 0/1 nodes are available: 1 node(s) didn't match Pod's node affinity/selector.

Are you using the latest version of the project?

You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.

• v0.1.3

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

• Mac OS, ARM64 arch, microk8s

(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here

• Bootstrap yaml has a node affinity for relay-agent which needs to be removed

nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
- key: kubernetes.io/arch
operator: In
values:
- amd64

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

Expected vs actual behavior

Even after I do a delete from the dashboard, and if kubectl is already open, I'm still able to perform operations on the cluster for a few minutes. Only after a while it starts throwing error. (image attached)

Steps to reproduce the bug

1. Import a cluster to Paralus
2. Open web kubectl (prompt) & execute some command i.e. kubectl get pods
3. Delete the cluster from the UI, but clicking the delete cluster. Ensure the web-kubectl screen is still open
4. After the cluster has been deleted from the UI, execute another command kubectl create ns testns followed by a 'kubectl get ns' - you'll observe that the namespace is created as well as listing command works even though the cluster is deleted from the UI.

Are you using the latest version of the project?

NAME     	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART     	APP VERSION
myrelease	paralus  	1       	2022-10-14 19:08:59.321602061 +0530 IST	deployed	ztka-0.1.7	v0.1.6    

What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!

clientVersion:
  buildDate: "2022-05-03T13:46:05Z"
  compiler: gc
  gitCommit: 4ce5a8954017644c5420bae81d72b09b735c21f0
  gitTreeState: clean
  gitVersion: v1.24.0
  goVersion: go1.18.1
  major: "1"
  minor: "24"
  platform: linux/amd64
kustomizeVersion: v4.5.4
serverVersion:
  buildDate: "2022-08-17T18:47:37Z"
  compiler: gc
  gitCommit: 95ee5ab382d64cfe6c28967f36b53970b8374491
  gitTreeState: clean
  gitVersion: v1.24.4
  goVersion: go1.18.5
  major: "1"
  minor: "24"
  platform: linux/amd64

Screenshot

Suggestions

Can we do something about it? Like maybe running a kubectl delete ns paralus-system in the background as soon as the cluster is deleted from the UI.

• I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
• I'm using the latest version of the project.

ref: https://bun.uptrace.dev/guide/soft-deletes.html#introduction