Implement chart for HashiCorp Vault Connector and include it as dependency for the umbrella CZERTAINLY chart.

This issue was automatically created by Allstar.

Security Policy Violation
Did not find any owners of this repository
This policy requires all repositories to have a user or team assigned as an administrator. A responsible party is required by organization policy to respond to security events and organization requests.

To add an administrator From the main page of the repository, go to Settings -> Manage Access.
(For more information, see https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories)

Alternately, if this repository does not have any maintainers, archive or delete it.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Encrypted secrets were detected in the repository config. This feature has been deprecated. Please migrate them to this portal. See the guide at http://docs.renovatebot.com/mend-hosted/migrating-secrets/
• WARN: Invalid registry response

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update helm/kind-action action to v1.10.0
• Update mailserver/docker-mailserver Docker tag to v14
• Update postgres Docker tag to v16
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch develop

⚠️ There is an updated version of this policy result! Click here to see the latest update

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

The securityContext should be defined for every chart that will provide hardening.
At least the following should be implemented as part of the securityContext:

• disallow privileged = do not allow pods to specify securityContext.privileged or allowPrivilegeEscallation
• disallow root user = define runAsNonRoot or runAsUser > 0 in securityContext
• disallow sysctls = disallow changing kernel parameters of worker nodes = cannot define sysctls in securityContext
• require read only root filesystem = pods must define, that their root filesystem (from docker image) is mounted readonly (readOnlyRootFilesystem: true in securityContext)

There should be options for ephemeral volume that is needed in some cases to have read-only filesystem.
Memory:

        - name: ephemeral
          emptyDir:
            sizeLimit: "1Mi"
            medium: "Memory"

Storage:

        - name: ephemeral
          ephemeral:
            volumeClaimTemplate:
              spec:
                accessModes: [ "ReadWriteOnce" ]
                # configurable option to select storage class
                storageClassName: "scratch-storage-class"
                resources:
                  requests:
                    storage: 1Mi

This issue was automatically created by Allstar.

Security Policy Violation
Security policy not enabled.
A SECURITY.md file can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible. Examples of secure reporting methods include using an issue tracker with private issue support, or encrypted email with a published key.

To fix this, add a SECURITY.md file that explains how to handle vulnerabilities found in your repository. Go to https://github.com/CZERTAINLY/CZERTAINLY-Helm-Charts/security/policy to enable.

For more information, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

CZERTAINLY deployment fails when executed behind intercepting HTTPS proxy. Such proxies are using their own CA to sign certificates of visited sites. And unkown CA causes core-deployment to fail with error:

exited with 1: 140516034980680:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1919:
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.14/main: Permission denied
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.14/main: No such file or directory
140516034980680:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1919:
ERROR: https://dl-cdn.alpinelinux.org/alpine/v3.14/community: Permission denied
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.14/community: No such file or directory

that is caused by running apk add curl at line 130 of core-deployment and it fails because of unknown CA from intercepting HTTPS proxy.

Alpine Linux seams to be using same concept for installing custom CA certificates as Debian:

• put certificate into /usr/local/share/ca-certificates directory
• call update-ca-certificates

Hack used to verify solution

$ cat <<EOF > proxy-certificates.yaml
apiVersion: v1
kind: Secret
metadata:
  namespace: czertainly
  name: proxy-certificates
type: Opaque
stringData:
  proxy-certificates.pem: |+
    -----BEGIN CERTIFICATE-----
    MIIDfTCCAmWgAwIBAgIUV6fuZZIcGWpKtihdv7IaVt/m0C0wDQYJKoZIhvcNAQEL
    BQAwTjELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxFDASBgNVBAoM
    C1NFTUlLT1ZBIENBMRQwEgYDVQQDDAtTRU1JS09WQSBDQTAeFw0yMzAxMDIxNTU5
    MDZaFw0zMjEyMzAxNTU5MDZaME4xCzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21l
    LVN0YXRlMRQwEgYDVQQKDAtTRU1JS09WQSBDQTEUMBIGA1UEAwwLU0VNSUtPVkEg
    Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDEuChlAGrzVAi0dbUz
    bX7DSnDw4+EWsybsVPnFInWIg2ZeuOWb2/DayGgYYfDbum6i0ZX+TrRnFHnxyvYV
    7Z341h/7pHMllj3uOybbQLvUFSDRIjc/+ZFY7hAVcDtflNINs7bNYlaH5M1GPELu
    13SOtDlqFO38U3gdjOMNc6bZlDOk9ZToLPPYapQRhrWbSlQNOqlTBiEqqu7X+ISe
    FrM1AHHc+1ju3mSvztrJGCZV6nyY8xEMxA0G3/j0sqf3oe9LuKuqcMS9fijVSu4O
    z3VilBReElDCZa07hv1sLTXe5gmJ4W7h6HB07/VwAXibZm/t4wph0YGT/uu5TBwS
    IC/NAgMBAAGjUzBRMB0GA1UdDgQWBBTirBfuwIBHdYS9SbxVhfn6KiZNUjAfBgNV
    HSMEGDAWgBTirBfuwIBHdYS9SbxVhfn6KiZNUjAPBgNVHRMBAf8EBTADAQH/MA0G
    CSqGSIb3DQEBCwUAA4IBAQAXpJeInwe33ZDlv9tzQ8AFu4S7N7tBvCJ2RBmpJEc9
    LnAL9LlXaSkzv+AMGcsEt2vvG0ypVhLMKZ7ygLVuKe5Bek2OODPaZka/hosxLCF/
    FzN/ckOQxWtopqqURdr7LMMj9D+5s/K2CTFGCb4SLRv1IXyJryN2tAZFFKMNZkYF
    zZ1Toq5lC6NW7yw8SifwVoTtDLGIVuTvMuTelqB3xZiLkpbqNmZORoM2mpvUF3PK
    Y+Cn6Q4Jxp27irjq7z1IVnUZGEBkxHMOdDMTBBwjOjPNy85mu6ZzUsazr2b2lVdT
    gc5SPYP/BufLw40tbh6ezrI+5zjnHUjRZbKxLXx3C9zB
    -----END CERTIFICATE-----
EOF
$ kubectl apply -f proxy-certificates.yaml
$ kubectl edit -n czertainly deployment/core-deployment
# add line 'cat /etc/ssl/certs/proxy-certificates.pem >> /etc/ssl/certs/ca-certificates.crt' into postStart like:
        lifecycle:
          postStart:
            exec:
              command:
              - sh
              - -c
              - |
                cat /etc/ssl/certs/proxy-certificates.pem >> /etc/ssl/certs/ca-certificates.crt &&
# mount proxy-certificates as volume:
        volumeMounts:
        ....
        - mountPath: /etc/ssl/certs/proxy-certificates.pem
          name: proxy-certificates
          subPath: proxy-certificates.pem
# define volume:
      volumes:
      ...
      - name: proxy-certificates
        secret:
          defaultMode: 420
          secretName: proxy-certificates

Downloaded image of alpine linux have in /etc/ssl/certs only ca-certificates.crt but after complete container creation the directory /etc/ssl/certs is fully populated with links to trusted certificates by their name and subject cashes with .0-n extensions. So I think it should be better follow Debian like approach described on StackOverflow.

Add support for deployment of Keystore Entity Provider.
This mean implementation of Keystore Entity Provider sub-chart and support in the czertainly umbrella chart.

Currently keycloak-internal subchart requires that keycloak schema in the database already exists.

The helm chart should be improved to check if the keycloak schema exists, and if not, create it.

Hello,
I have installed 0.0.0 version of CZERTAINLY, in custom .yaml values I have also enabled ct logs provider with the following code:

ctLogsDiscoveryProvider:
enabled: true
image:
tag: develop-latest
pullPolicy: Always
logging:
level: "DEBUG"

I can not see the connector in connectors list though, even after opening CZERTAINLY in anonymous windows or after pressing CTRL + F5. But CT logs pod is running, can be seen on screenshot.

Best Regards,
Denys Doloban

We can define global.image.registry parameter to globally change the docker registry for all charts.
However, the repository name is sill locally defined and in some case it needs to be changed also on the global level (for example when we maintain private docker registry with custom repositories/projects).

It would be helpful if the current image.repository parameter is split into image.repository and image.name. Then we can create global.image.repository that will be applied to all charts without need to write it specifically for all of them.

An example:

global:
  image:
    registry: ""
    repository: ""

image:
  # default registry name
  registry: docker.io
  repository: 3keycompany
  name: czertainly-core
  tag: 2.7.1

This will produce image as docker.io/3keycompany/czertainly-core:2.7.1

global:
  image:
    registry: myregistry.com
    repository: ""

image:
  # default registry name
  registry: docker.io
  repository: 3keycompany
  name: czertainly-core
  tag: 2.7.1

Will produce myregistry.com/3keycompany/czertainly-core:2.7.1

global:
  image:
    registry: myregistry.com
    repository: czertainly/project

image:
  # default registry name
  registry: docker.io
  repository: 3keycompany
  name: czertainly-core
  tag: 2.7.1

Will produce myregistry.com/czertainly/project/czertainly-core:2.7.1

This issue was automatically created by Allstar.

Security Policy Violation
Project is out of compliance with Dangerous Workflow policy: dangerous workflow patterns detected

Rule Description
Dangerous Workflows are GitHub Action workflows that exhibit dangerous patterns that could render them vulnerable to attack. A vulnerable workflow is susceptible to leaking repository secrets, or allowing an attacker write access using the GITHUB_TOKEN. For more information about the particular patterns that are detected see the Security Scorecards Documentation for Dangerous Workflow.

Remediation Steps
Avoid the dangerous workflow patterns. See this post for information on avoiding untrusted code checkouts. See this document for information on avoiding and mitigating the risk of script injections.

Dangerous Patterns Found

• .github/workflows/check_develop_charts.yml[51]:untrusted code checkout '${{ github.event.pull_request.head.ref }}'

Additional Information
This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

The OpenTelemtry is becoming a standard for observability.
CZERTAINLY Helm chart and its subcharts should support OTEL for collecting traces, metrics, and logs.

The scope of this issue is to start producing signals, when enabled. Collecting and using signals are out of scope of this issue.

OTEL support should be configurable on global and local (chart) level. When the global temeletry is enabled, all components that supports OTEL should enable it also.

Through the configuration, user should be able to select signals that should be produced and collected:

• traces
• metrics
• logs

For example:

global:
  opentelemetry:
    enabled: true
    signals:
      traces:
        enabled: true
      metrics:
        enabled: true
      logs:
        enabled: true

Components should produce only signals that are configured (not true for logs, logs are by default produced in the system).

Describe the bug

After changing hostName in values file, the new value is not correctly propagated to Keycloak.

To Reproduce
Steps to reproduce the behavior:

1. Install CZERTAINLY with some hostname, for example czertainly11.local.
2. Check everything is working including login with Keycloak.
3. Change hostname to some new value, redeploy using helm.
4. Try to login with username / password, ie. using Keycloak and see error Invalid parameter: redirect_uri. In logs of Keycloak is error message 2024-08-01 07:37:50,362 WARN [org.keycloak.events] (executor-thread-3) type="LOGIN_ERROR", realmId="1595e715-e7d0-417a-8df5-77bbdde4e8d8", clientId="kong", userId="null", ipAddress="192.168.1.12", error="invalid_redirect_uri", redirect_uri="https://czertainly-big.local/login/"

Expected behavior

I think it should be able to change hostname with change in values files for all components of CZERTAINLY.

Screenshots

Additional context

During startup Keycloak print in logs:

2024-08-01 07:27:08,410 INFO  [org.keycloak.exportimport.singlefile.SingleFileImportProvider] (main) Full importing from file /opt/keycloak/bin/../data/import/czertainly_realm.json
2024-08-01 07:27:09,306 INFO  [org.keycloak.exportimport.util.ImportUtils] (main) Realm 'CZERTAINLY' already exists. Import skipped
2024-08-01 07:27:09,318 INFO  [org.keycloak.exportimport.dir.DirImportProvider] (main) Importing from directory /opt/keycloak/bin/../data/import

I underand this that any change in in czertanly_realm.json is ignored after initial import.

Note on screenshot that all URLs have changed, except of the one for kong client. I think that instead of "rootUrl" : "https://{{ required "Hostname must be provided: .Values.czertainly.hostName" $hostName }}", we should use "rootUrl" : "${authBaseUrl}", which is used for example with clientID account-console.

I can test it and when prove be right I can prepare PR for this change. But not right now. If you agree, please assign me this issue and I will proceed.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: Failed to decrypt field password. Please re-encrypt and try again.

Request and limits should be defined for all charts:
require pods requests and limits = pods must define how much ram and cpu they require for them. It helps Kubernetes scheduler to place them on worker node with enough resources:
Resource Management for Pods and Containers

In some cases there is a need to add init and sidecar containers to deployment, however, the charts do not support this currently.

The proposed solution would be to add initContainers: [] and sidecarContainers: [] into global configuration of the umbrella chart to be distributed to all sub-charts, if needed. For example, when you need to collect and ship logs from all deployments, it will be handy, instead of adding the same containers to every chart.

The initContainers: [] and sidecarContainers: [] should be also defined as local parameters for every chart in case they should be defined only for some of them (specific set of deployments).

initContainers: [] and sidecarContainers: [] can contain definition of multiple containers and they should be completely defined and rendered as it is to deployments.

Currently the image section in the values.yaml has the following structure:

image:
  repository: 3keycompany/czertainly-core
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

However, it would be helpful to extend this configuration with registry in case the images are stored in different registry. Although the repository can contain also registry in its name, it would be more user friendly if the registry can be also configured as global parameter and set it for all subcharts.

The proposed change is to have:

image:
  # default registry name
  registry: docker.io
  repository: 3keycompany/czertainly-core
  # overrides the image tag whose default is the chart appVersion.
  tag: ""
  # the digest to be used instead of the tag
  digest: ""
  pullPolicy: IfNotPresent
  pullSecrets: []

The spec.selector is an immutable field of the deployment. When upgrading Helm chart with changed selectors, the upgrade will failed with the similar reason:

UPGRADE FAILED: cannot patch \"api-gateway-deployment\" with kind Deployment: Deployment.apps \"api-gateway-deployment\" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{\"app.kubernetes.io/instance\":\"czertainly-tlm\", \"app.kuberne...

The selectors for each chart should be updated to be consistent and avoid any changes in the future that may cause upgrade failed. The only solution for failed upgrade is to delete application and install it again.

The utils-service can be deployed as part of the umbrella czertainly chart, however the configuration of the API gateway to access the utils-service is missing, therefor it cannot be access by remote clients, only by internal services.

The utils-service configuration should be available for the API gateway when enabled.

Each chart and sub-chart should include readiness and liveness probes:
Configure Liveness, Readiness and Startup Probes

The api-gateway-kong chart does support enabling service as NodePort, however, it does not provide parameters to configure nodePort.

Parameters and templates should be extended with 2 nodePorts:

• for user service
• for admin service (which is typically used for health checks)

When installing on new on a new system, Keycloak is very often failing. api-gateway-deployment is missing:

...
      hostAliases:
      - ip: "10.43.116.241"
        hostnames:
        - "czertainly.local"

and user is getting error Kong Error. Even when values.yaml contains:

...
# this is needed only for KeyCloak
apiGateway:
  hostAliases:
    resolveInternalKeycloak: true
  trustedIps: "0.0.0.0/0,::/0"
...

Steps to reproduce

• Take Virtual Appliance
• Fully configure it to install all features of version 2.7.1
• Remove last task, CZERTAINLY instalation, from file /etc/czertainly-ansible/roles/czertainly/tasks/main.yml
• Exec complete instalation and wait for it to fail (because that last task is removed)
• This is moment when you have clean, ready to use k8s sys
• Enter system shell, exec /usr/sbin/helm --version=2.7.1 upgrade -i --reset-values --wait --timeout 10m --values=/root/install/czertainly-values.yaml --values=/root/install/czertainly-values.local.yaml czertainly-tlm oci://harbor.3key.company/czertainly-helm/czertainly -n czertainly --debug 2>&1 | tee /tmp/2.7.1-helm-install-ENABLED-keycloak.log
• check if keycloak is working (loggin to https://czertainly.local/administrator/ without cert will fail if it is not working)
• Enter system shell again and exec /usr/sbin/helm --version=2.8.0 upgrade -i --reset-values --wait --timeout 10m --values=/root/install/czertainly-values.yaml --values=/root/install/czertainly-values.local.yaml czertainly-tlm oci://harbor.3key.company/czertainly-helm/czertainly -n czertainly --debug 2>&1 | tee /tmp/2.8.0-helm-upgrade-ENABLED-keycloak.log
• at this moment will be keycloak typically working

File /tmp/2.7.1-helm-install-ENABLED-keycloak.log is lacking section with hostAliases, so keyCloak is not working. File /tmp/2.8.0-helm-upgrade-ENABLED-keycloak.log typicaly has section hostAliases. And keycloak is working.

Notes

• Steps above are not 100%
• Installing 2.8.0 with disabled Keycloak and enabling it is typically not enough, but once it was good
• mentioned files are attached:
  2.8.0-helm-upgrade-ENABLED-keycloak.log
  2.7.1-helm-install-ENABLED-keycloak.log

The current kong proxy does not forward real hostname, protocol and port when the IP address of the source is not trusted. It has impact for example on generating ACME URLs.

It can be solved by allowing all IP addresses, which is not good security practice (although this the entry point and there is always firewall in front of the application).

Option to define list of trusted IP addresses, subnets, is vital for the configuration of the proxy.

Describe the bug
Hooks where public images are used do not have an imagePullPolicy defined in the Helm chart. Without it, it is not possible to use images stored in the internal registry, which is defined in the global parameters.

To Reproduce

1. Set global.image.registry, repository, pullSecrets to own registry and repository
2. Deploy app Czertainly to k8S cluster
3. czertainly-add-hosts-to-deployment-job-xxxxx pod not started, because ErrPullImage
4. Failed to pull image "registry_host:port/czertainly/kubectl:1.27.3": failed to pull and unpack image "registry_host:port/czertainly/kubectl:1.27.3": failed to resolve reference "registry_host:port/czertainly/kubectl:1.27.3": failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://registry_host/jwt/auth?scope=repository%3Aczertainly%2Fkubectl%3Apull&service=container_registry: 403 Forbidden

Expected behavior
A pull image will be performed and pod will start as with other microservices

Desktop (please complete the following information):

• Czertainly ver. 2.11
• OS: rocky 9.3
• Helm ver. 3.10
• k8s version: 1.28