Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question][DevOps] Deploy devlake with managed GCP Cloud database service (with SSL enabled) #7928

Open
pmallampati-sift opened this issue Aug 21, 2024 · 32 comments
Assignees
Labels
type/question This issue is a question

Comments

@pmallampati-sift
Copy link

Question

Hi currently we are trying to deploy devlake in our dev env. We are trying to integrate devlake using helm chart with managed GCP Cloud database service.
Our DB is SSL enabled and we don't see how to pass the SSL certs in the DB conn string part of helm chart.
Could you please let us know what additional params we need to use for using SSL in additional to below params we pass to helm command.

- `mysql.useExternal`: this should be `true`
- `mysql.externalServer`: use your RDS instance's IP address or domain name.
- `mysql.externalPort`: use your RDS instance's database port.
- `mysql.username`: use your `username` for access RDS instance's DB
- `mysql.password`: use your `password` for access RDS instance's DB
- `mysql.database`: use your RDS instance's DB name, you may need to create a database first with `CREATE DATABASE <DB name>;`

Screenshots

If applicable, add screenshots to help explain.

Additional context

Add any other context here.

@pmallampati-sift pmallampati-sift added the type/question This issue is a question label Aug 21, 2024
@pmallampati-sift pmallampati-sift changed the title [Question][Module Name] Question title Deploy devlake with mysql hosted on GCP with ssl enabled [Question][Module Name] Deploy devlake with managed GCP Cloud database service (with SSL enabled) Aug 21, 2024
Copy link

dosubot bot commented Aug 21, 2024

Hello @pmallampati-sift! I'm here to help you with any questions or issues you might have. I can assist with bug fixes, troubleshooting, and becoming a contributor.

To deploy DevLake with a MySQL database hosted on GCP with SSL enabled using a Helm chart, you need to pass the SSL certificates in the DB connection string. Here are the steps to achieve this:

  1. Create a Kubernetes secret with the necessary database connection details and SSL certificates:

    kubectl create secret generic devlake-mysql-auth \
      --from-literal=MYSQL_USER=<your-username> \
      --from-literal=MYSQL_PASSWORD=<your-password> \
      --from-literal=MYSQL_DATABASE=<your-database> \
      --from-literal=MYSQL_ROOT_PASSWORD=<your-root-password> \
      --from-literal=DB_URL='mysql://<your-username>:<your-password>@<dbserver>:<port>/<database>?charset=utf8mb4&parseTime=True&tls=custom' \
      --from-file=ca-cert=<path-to-ca-cert> \
      --from-file=client-cert=<path-to-client-cert> \
      --from-file=client-key=<path-to-client-key>
  2. Install the DevLake Helm chart and reference the created secret:

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    ENCRYPTION_SECRET=$(openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1)
    helm install devlake devlake/devlake \
      --set mysql.useExternal=true \
      --set mysql.externalServer=<dbserver> \
      --set mysql.externalPort=<port> \
      --set mysql.username=<your-username> \
      --set mysql.password=<your-password> \
      --set mysql.database=<your-database> \
      --set option.connectionSecretName=devlake-mysql-auth \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET

Replace <your-username>, <your-password>, <your-database>, <your-root-password>, <dbserver>, <port>, <path-to-ca-cert>, <path-to-client-cert>, and <path-to-client-key> with your actual values [1].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

pmallampati-sift commented Aug 21, 2024

Per above suggestion when deployed with above config it says unknown value tls=custom for tls option.
Tried with tls=skip-verify which gave access denied error.

  --from-literal=DB_URL='mysql://<your-username>:<your-password>@<dbserver>:<port>/<database>?charset=utf8mb4&parseTime=True&tls=custom' \

error log from DB

textPayload: "time="2024-08-21 19:27:26" level=info msg="\x1b[35m/app/core/runner/db.go:154\n\x1b[0m\x1b[31m[error] \x1b[0mfailed to initialize database, got error invalid value / unknown config name: custom""

Copy link

dosubot bot commented Aug 21, 2024

To correctly configure the DB_URL for deploying DevLake with a managed GCP Cloud database service using SSL, you should use the tls=custom option and specify the path to your CA certificate. Here is an example configuration:

DB_URL=mysql://<your-username>:<your-password>@<dbserver>:<port>/<database>?charset=utf8mb4&parseTime=True&tls=custom&ca-cert=/path/to/your/ca-certificate.crt

Make sure to replace /path/to/your/ca-certificate.crt with the actual path to your CA certificate file. This configuration ensures that the SSL certificate is verified using the provided CA certificate. If you encounter issues with tls=custom, you can also try tls=skip-verify as a fallback, but be aware that it will not verify the SSL certificate [1][2][3].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

@dosu
Hi We are seeing below error when deploying with SSL

"Wraps: (3) x509: cannot validate certificate for X.X.X.X(ip) because it doesn't contain any IP SANs"

Copy link

dosubot bot commented Aug 22, 2024

To resolve the "x509: cannot validate certificate for X.X.X.X(ip) because it doesn't contain any IP SANs" error when deploying DevLake with SSL, you can add your root CA to the devlake container. Here is an example of how to do this using docker-compose:

devlake:
  image: apache/devlake:v...
  ...
  volumes:
    ...
    - /path/to/your/rootCA.crt:/usr/local/share/ca-certificates/rootCA.crt
  command: [ "sh", "-c", "update-ca-certificates; lake" ]
  ...

This approach involves mounting your rootCA.crt into the devlake container and adding a command node to install the mounted certificate. Additionally, if you encounter a "Test Connection" error, you can set the environment variable IN_SECURE_SKIP_VERIFY=true for the devlake container to bypass certificate verification. Note that "GitExtractor" may fail to clone the repository due to certificate verification, as neither gogit nor git2go supports insecure HTTPS [1][2][3][4][5].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

@dosu
We are using clouds sql from GCP and in the generated ssl certs we have CN=Google Cloud SQL Server CA but missing SAN name in it.
But lake is trying to verify SAN in the certificates.
Any workarounds.

Copy link

dosubot bot commented Aug 23, 2024

To address the issue with the missing SAN names in the SSL certificates generated by GCP Cloud SQL, you can add your root CA to the devlake container and update the CA certificates within the container. Here is an example of how to do this using docker-compose:

devlake:
  image: apache/devlake:v...
  ...
  volumes:
    ...
    - /path/to/your/rootCA.crt:/usr/local/share/ca-certificates/rootCA.crt
  command: [ "sh", "-c", "update-ca-certificates; lake" ]
  ...

Since you are using Helm, you can adapt this approach by adding the root CA to your Helm chart configuration. Here is an example of how to do this:

  1. Create a Kubernetes secret with your root CA:

    kubectl create secret generic root-ca-cert --from-file=rootCA.crt=/path/to/your/rootCA.crt
  2. Update your Helm chart to mount the root CA and update the CA certificates:

    volumeMounts:
      - name: newcerts
        mountPath: /etc/ssl/certs
      - name: root-ca-cert
        mountPath: /usr/local/share/ca-certificates/rootCA.crt
    volumes:
      - name: newcerts
        secret:
          secretName: newcerts
      - name: root-ca-cert
        secret:
          secretName: root-ca-cert
    initContainers:
      - name: update-ca-certificates
        image: busybox
        command: ["sh", "-c", "update-ca-certificates"]
        volumeMounts:
          - name: root-ca-cert
            mountPath: /usr/local/share/ca-certificates/rootCA.crt
  3. Ensure the IN_SECURE_SKIP_VERIFY=true environment variable is set:

    env:
      - name: IN_SECURE_SKIP_VERIFY
        value: "true"

This setup should help in cases where the generated SSL certificates have CN=Google Cloud SQL Server CA but are missing SAN names, and mounting the required certs and setting IN_SECURE_SKIP_VERIFY=true does not resolve the issue [1][2][3].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

pmallampati-sift commented Aug 23, 2024

@dosu
I have executed above suggested steps but still I am getting same error
Also generated a rootCA.crt using the DB dns and placed below certs in/etc/ssl/certs folder.

devlake-client-key.pem
devlake-client-cert.pem
devlake-server-ca.pem
rootCA.crt

Also placed rootCA.crt under /usr/local/share/ca-certificates in lake container

Wraps: (3) x509: cannot validate certificate for 10.252.182.24 because it doesn't contain any IP SANs

Also in the init container I am seeing below error.

ERROR 2024-08-23T06:13:29.444710841Z [resource.labels.containerName: update-ca-certificates] sh: update-ca-certificates: not found

Copy link

dosubot bot commented Aug 23, 2024

To resolve the "x509: cannot validate certificate for 10.252.182.24 because it doesn't contain any IP SANs" error when deploying DevLake with SSL, you need to ensure that your root CA is properly added to the devlake container. Given that you are seeing an "update-ca-certificates: not found" error in the init container, it indicates that the update-ca-certificates command is not available in the container's environment.

Here is a solution based on the provided documentation:

  1. Mount your rootCA.crt into the devlake container:
    Ensure that your root CA certificate is mounted correctly into the container.

  2. Install the necessary package to use update-ca-certificates:
    Modify the command node to install the required package before running update-ca-certificates.

Here is an example of how you can modify your docker-compose file to achieve this:

devlake:
  image: apache/devlake:v...
  ...
  volumes:
    ...
    - /path/to/your/rootCA.crt:/usr/local/share/ca-certificates/rootCA.crt
  command: [ "sh", "-c", "apt-get update && apt-get install -y ca-certificates && update-ca-certificates; lake" ]
  ...

This command ensures that the ca-certificates package is installed, which provides the update-ca-certificates command, and then updates the CA certificates before starting the lake process.

Additionally, if you encounter issues with self-signed certificates, you can set the environment variable IN_SECURE_SKIP_VERIFY=true for the devlake container to bypass certificate verification during the "Test Connection" phase. However, this is not recommended for production environments due to security concerns.

For more detailed troubleshooting, you can refer to the Configuration and Blueprint Troubleshooting section in the DevLake documentation. Specifically, the section on "Failed to collect data from the server with a self-signed certificate" provides relevant information and solutions [1][2][3][4][5].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

@dosu
Could you please give instructions on how to execute below steps via helm chart.

Install the necessary package to use update-ca-certificates:
Modify the command node to install the required package before running update-ca-certificates.

Copy link

dosubot bot commented Aug 23, 2024

To execute the steps for installing the necessary package and running update-ca-certificates via the Helm chart, you can use an init container to handle the installation and update process. Here is how you can modify your Helm chart configuration to achieve this:

  1. Create a Kubernetes secret with your root CA:

    kubectl create secret generic root-ca-cert --from-file=rootCA.crt=/path/to/your/rootCA.crt
  2. Update your values.yaml file to include the init container and mount the root CA:

    lake:
      initContainers:
        - name: update-ca-certificates
          image: debian:bullseye
          command: ["sh", "-c", "apt-get update && apt-get install -y ca-certificates && cp /mnt/rootCA.crt /usr/local/share/ca-certificates/rootCA.crt && update-ca-certificates"]
          volumeMounts:
            - name: root-ca-cert
              mountPath: /mnt
    
      volumes:
        - name: root-ca-cert
          secret:
            secretName: root-ca-cert
  3. Install the Helm chart with the updated configuration:

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    ENCRYPTION_SECRET=$(openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1)
    helm install devlake devlake/devlake \
      --set mysql.useExternal=true \
      --set mysql.externalServer=<dbserver> \
      --set mysql.externalPort=<port> \
      --set mysql.username=<your-username> \
      --set mysql.password=<your-password> \
      --set mysql.database=<your-database> \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET \
      --values values.yaml

Replace <dbserver>, <port>, <your-username>, <your-password>, and <your-database> with your actual values.

This configuration ensures that the ca-certificates package is installed, the root CA certificate is copied to the appropriate location, and the CA certificates are updated before the main lake container starts.

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

pmallampati-sift commented Aug 23, 2024

@dosu

Per your suggestion if we do below step, do we still need to create the devlake-mysql-auth with DB url and SSL certs as you have mentioned here #7928 (comment)

`lake:
initContainers:
- name: update-ca-certificates
image: debian:bullseye
command: ["sh", "-c", "apt-get update && apt-get install -y ca-certificates && cp /mnt/rootCA.crt /usr/local/share/ca-certificates/rootCA.crt && update-ca-certificates"]
volumeMounts:
- name: root-ca-cert
mountPath: /mnt

volumes:
- name: root-ca-cert
secret:
secretName: root-ca-cert
`

Copy link

dosubot bot commented Aug 23, 2024

Yes, you still need to create the devlake-mysql-auth with the database URL and SSL certificates even if you implement an init container to update CA certificates. The init container approach is for updating CA certificates within the devlake container, but it does not replace the need for the devlake-mysql-auth configuration which is required for database authentication and SSL setup [1].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

pmallampati-sift commented Aug 23, 2024

@dosu

In that case its still not working with above suggestion I was able to get the both below init containers up and running.

  • update-ca-certificates
  • database-wait

But after that the lake container is still failing with

Wraps: (3) x509: cannot validate certificate for because it doesn't contain any IP SANs

Copy link

dosubot bot commented Aug 23, 2024

To resolve the "x509: cannot validate certificate for 10.252.182.24 because it doesn't contain any IP SANs" error, you can bypass the certificate verification by setting the IN_SECURE_SKIP_VERIFY environment variable to true. This is not recommended for production environments due to security concerns, but it can help you move forward.

Here is how you can update your Helm chart configuration to include this environment variable:

  1. Update your values.yaml file to include the IN_SECURE_SKIP_VERIFY environment variable:

    lake:
      env:
        - name: IN_SECURE_SKIP_VERIFY
          value: "true"
  2. Install the Helm chart with the updated configuration:

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    ENCRYPTION_SECRET=$(openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1)
    helm install devlake devlake/devlake \
      --set mysql.useExternal=true \
      --set mysql.externalServer=<dbserver> \
      --set mysql.externalPort=<port> \
      --set mysql.username=<your-username> \
      --set mysql.password=<your-password> \
      --set mysql.database=<your-database> \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET \
      --values values.yaml

Replace <dbserver>, <port>, <your-username>, <your-password>, and <your-database> with your actual values.

This configuration will bypass the certificate verification, allowing the lake container to connect to the database despite the missing IP SANs in the certificate [1][2][3][4][5].

To continue talking to Dosu, mention @dosu.

@klesh
Copy link
Contributor

klesh commented Aug 26, 2024

It appears that MySQL SSL connections are currently not supported. For now, I recommend trying a connection without an SSL certificate.

@Startrekzky Startrekzky changed the title [Question][Module Name] Deploy devlake with managed GCP Cloud database service (with SSL enabled) [Question][DevOps] Deploy devlake with managed GCP Cloud database service (with SSL enabled) Aug 26, 2024
@pmallampati-sift
Copy link
Author

Thank you @klesh yes mysql SSL were not supported, but we were able to resolve the issue by connecting using cloudsql-auth-proxy.

@pmallampati-sift
Copy link
Author

Hi @dosu
How to add new plugins to devlake using helm chart.

Copy link

dosubot bot commented Aug 26, 2024

To add new plugins to DevLake using a Helm chart, follow these steps:

  1. Modify the values.yaml file:
    Add the new plugin configuration under the lake.plugins section in the values.yaml file. For example, if you are adding a plugin named new-plugin, you might add:

    lake:
      plugins:
        - name: new-plugin
          image: your-docker-repo/new-plugin:latest
          env:
            - name: PLUGIN_SETTING
              value: "some-value"
  2. Install or upgrade the Helm chart with the updated values.yaml:
    Use the helm install or helm upgrade command with the updated values.yaml file.

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    ENCRYPTION_SECRET=$(openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1)
    helm upgrade devlake devlake/devlake --version=0.20.0-beta8 --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET -f values.yaml

This will apply the new configuration and include the new plugin in your DevLake installation [1][2].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

hi @dosu
Can we integrate devlake with OKTA SSO config....?

Copy link

dosubot bot commented Aug 27, 2024

Currently, there is no specific documentation or configuration guide for integrating DevLake with OKTA SSO. However, DevLake does support SSO integration through the authproxy service, which uses oauth2-proxy. This service can be configured to work with various OAuth2 providers, including OKTA.

Here is a general approach to integrate DevLake with OKTA SSO using oauth2-proxy:

  1. Configure oauth2-proxy with OKTA settings:
    Update the docker-compose-dev.yml file to include the necessary OKTA configuration for oauth2-proxy.

    authproxy:
      image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0-amd64
      network_mode: "host"
      ports:
        - 4180:4180
      env_file:
        - ./.env
      environment:
        OAUTH2_PROXY_PROVIDER: oidc
        OAUTH2_PROXY_PROVIDER_DISPLAY_NAME: OKTA
        OAUTH2_PROXY_COOKIE_SECRET: <your-cookie-secret>
        OAUTH2_PROXY_COOKIE_DOMAINS: localhost:4180
        OAUTH2_PROXY_COOKIE_SECURE: 'false'
        OAUTH2_PROXY_EMAIL_DOMAINS: '*'
        OAUTH2_PROXY_OIDC_ISSUER_URL: https://<your-okta-domain>/oauth2/default
        OAUTH2_PROXY_CLIENT_ID: <your-client-id>
        OAUTH2_PROXY_CLIENT_SECRET: <your-client-secret>
        OAUTH2_PROXY_UPSTREAMS: http://localhost:4000
        OAUTH2_PROXY_HTTP_ADDRESS: http://0.0.0.0:4180
        OAUTH2_PROXY_REVERSE_PROXY: 'true'
        OAUTH2_PROXY_SKIP_AUTH_ROUTES: ^/grafana.*
  2. Deploy the updated configuration:
    Ensure that the authproxy service is deployed with the updated configuration.

  3. Update Helm chart for OKTA SSO:
    If you are using Helm, you can add the necessary environment variables and configurations in your values.yaml file.

    authproxy:
      enabled: true
      image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0-amd64
      env:
        - name: OAUTH2_PROXY_PROVIDER
          value: oidc
        - name: OAUTH2_PROXY_PROVIDER_DISPLAY_NAME
          value: OKTA
        - name: OAUTH2_PROXY_COOKIE_SECRET
          value: <your-cookie-secret>
        - name: OAUTH2_PROXY_COOKIE_DOMAINS
          value: localhost:4180
        - name: OAUTH2_PROXY_COOKIE_SECURE
          value: 'false'
        - name: OAUTH2_PROXY_EMAIL_DOMAINS
          value: '*'
        - name: OAUTH2_PROXY_OIDC_ISSUER_URL
          value: https://<your-okta-domain>/oauth2/default
        - name: OAUTH2_PROXY_CLIENT_ID
          value: <your-client-id>
        - name: OAUTH2_PROXY_CLIENT_SECRET
          value: <your-client-secret>
        - name: OAUTH2_PROXY_UPSTREAMS
          value: http://localhost:4000
        - name: OAUTH2_PROXY_HTTP_ADDRESS
          value: http://0.0.0.0:4180
        - name: OAUTH2_PROXY_REVERSE_PROXY
          value: 'true'
        - name: OAUTH2_PROXY_SKIP_AUTH_ROUTES
          value: ^/grafana.*
  4. Install or upgrade the Helm chart:
    Use the helm install or helm upgrade command with the updated values.yaml file.

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    helm upgrade devlake devlake/devlake --values values.yaml

This setup should help you integrate DevLake with OKTA SSO using oauth2-proxy. Make sure to replace placeholders like <your-cookie-secret>, <your-okta-domain>, <your-client-id>, and <your-client-secret> with your actual OKTA configuration values.

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

@dosu
How do I get value of OAUTH2_PROXY_COOKIE_SECRET to configure oauth2-proxy....?

Copy link

dosubot bot commented Aug 28, 2024

To generate a value for OAUTH2_PROXY_COOKIE_SECRET to configure oauth2-proxy, you can use a secure random string. This secret is used to encrypt the cookie data, so it should be a strong, random value.

Here are a few ways to generate this secret:

Using OpenSSL

You can use the openssl command to generate a random base64 string:

openssl rand -base64 32

Using Python

You can also use Python to generate a random string:

import os
import base64

print(base64.b64encode(os.urandom(32)).decode('utf-8'))

Using Linux Command Line

If you are on a Linux system, you can use the following command:

head -c32 /dev/urandom | base64

Example

Once you have generated the secret, it will look something like this:

s3cr3tK3yTh4tIsV3ryS3cur3AndR4nd0m==

You can then use this value in your values.yaml file or environment variable configuration for oauth2-proxy:

authproxy:
  enabled: true
  image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0-amd64
  env:
    - name: OAUTH2_PROXY_PROVIDER
      value: oidc
    - name: OAUTH2_PROXY_PROVIDER_DISPLAY_NAME
      value: OKTA
    - name: OAUTH2_PROXY_COOKIE_SECRET
      value: s3cr3tK3yTh4tIsV3ryS3cur3AndR4nd0m==
    - name: OAUTH2_PROXY_COOKIE_DOMAINS
      value: localhost:4180
    - name: OAUTH2_PROXY_COOKIE_SECURE
      value: 'false'
    - name: OAUTH2_PROXY_EMAIL_DOMAINS
      value: '*'
    - name: OAUTH2_PROXY_OIDC_ISSUER_URL
      value: https://<your-okta-domain>/oauth2/default
    - name: OAUTH2_PROXY_CLIENT_ID
      value: <your-client-id>
    - name: OAUTH2_PROXY_CLIENT_SECRET
      value: <your-client-secret>
    - name: OAUTH2_PROXY_UPSTREAMS
      value: http://localhost:4000
    - name: OAUTH2_PROXY_HTTP_ADDRESS
      value: http://0.0.0.0:4180
    - name: OAUTH2_PROXY_REVERSE_PROXY
      value: 'true'
    - name: OAUTH2_PROXY_SKIP_AUTH_ROUTES
      value: ^/grafana.*

Replace <your-okta-domain>, <your-client-id>, and <your-client-secret> with your actual OKTA configuration values.

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

pmallampati-sift commented Aug 28, 2024

@dosu
Per suggestion I have added the oauth2-proxy, settings to vaules.yml file, but still I get basic auth username/password pop up coming up.

Do we need to delete the pod resources and recreate from scratch...?

Copy link

dosubot bot commented Aug 28, 2024

To resolve the issue of the basic auth username/password pop-up still appearing after adding oauth2-proxy, you may need to ensure that the oauth2-proxy is correctly configured and that the old configurations are not interfering. Here are a few steps to troubleshoot and resolve this:

  1. Verify oauth2-proxy Configuration:
    Ensure that the oauth2-proxy configuration is correct and that it is properly integrated with your OKTA settings.

  2. Check Ingress Configuration:
    Make sure that your Ingress configuration is routing traffic through the oauth2-proxy. This typically involves updating the Ingress annotations to use oauth2-proxy.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: devlake-ingress
      annotations:
        nginx.ingress.kubernetes.io/auth-url: "https://<your-domain>/oauth2/auth"
        nginx.ingress.kubernetes.io/auth-signin: "https://<your-domain>/oauth2/start?rd=$request_uri"
    spec:
      rules:
        - host: <your-domain>
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: devlake
                    port:
                      number: 80
  3. Delete and Recreate Pods:
    If the configuration changes are not taking effect, you may need to delete the existing pods to ensure that the new configuration is applied. You can do this by deleting the pods, and Kubernetes will automatically recreate them with the updated configuration.

    kubectl delete pod -l app=devlake
  4. Check Logs:
    Check the logs of the oauth2-proxy and devlake pods to ensure that there are no errors and that the authentication flow is working as expected.

    kubectl logs <oauth2-proxy-pod-name>
    kubectl logs <devlake-pod-name>
  5. Update Helm Chart:
    Ensure that your Helm chart values are correctly set to use oauth2-proxy. Here is an example of what your values.yaml might look like:

    authproxy:
      enabled: true
      image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0-amd64
      env:
        - name: OAUTH2_PROXY_PROVIDER
          value: oidc
        - name: OAUTH2_PROXY_PROVIDER_DISPLAY_NAME
          value: OKTA
        - name: OAUTH2_PROXY_COOKIE_SECRET
          value: s3cr3tK3yTh4tIsV3ryS3cur3AndR4nd0m==
        - name: OAUTH2_PROXY_COOKIE_DOMAINS
          value: localhost:4180
        - name: OAUTH2_PROXY_COOKIE_SECURE
          value: 'false'
        - name: OAUTH2_PROXY_EMAIL_DOMAINS
          value: '*'
        - name: OAUTH2_PROXY_OIDC_ISSUER_URL
          value: https://<your-okta-domain>/oauth2/default
        - name: OAUTH2_PROXY_CLIENT_ID
          value: <your-client-id>
        - name: OAUTH2_PROXY_CLIENT_SECRET
          value: <your-client-secret>
        - name: OAUTH2_PROXY_UPSTREAMS
          value: http://localhost:4000
        - name: OAUTH2_PROXY_HTTP_ADDRESS
          value: http://0.0.0.0:4180
        - name: OAUTH2_PROXY_REVERSE_PROXY
          value: 'true'
        - name: OAUTH2_PROXY_SKIP_AUTH_ROUTES
          value: ^/grafana.*

After making these changes, redeploy the Helm chart:

helm upgrade devlake devlake/devlake --values values.yaml

By following these steps, you should be able to resolve the issue and ensure that the oauth2-proxy is correctly handling authentication.

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

@dosu
Did configuration per above message. I can see ingress got added but oauth2-proxy pod is not coming up.
I can only see 2 pods dev-lake and UI.

NAME                            READY   STATUS    RESTARTS        AGE
devlake-lake-   2/2     Running   1 (4m15s ago)   4m16s
devlake-ui    1/1     Running   0               4m16s

Copy link

dosubot bot commented Aug 28, 2024

To troubleshoot why the oauth2-proxy pod is not coming up, let's check a few things:

  1. Verify Helm Chart Configuration:
    Ensure that the oauth2-proxy configuration is correctly added to your values.yaml file. Here is an example configuration:

    authproxy:
      enabled: true
      image: quay.io/oauth2-proxy/oauth2-proxy:v7.4.0-amd64
      env:
        - name: OAUTH2_PROXY_PROVIDER
          value: oidc
        - name: OAUTH2_PROXY_PROVIDER_DISPLAY_NAME
          value: OKTA
        - name: OAUTH2_PROXY_COOKIE_SECRET
          value: s3cr3tK3yTh4tIsV3ryS3cur3AndR4nd0m==
        - name: OAUTH2_PROXY_COOKIE_DOMAINS
          value: localhost:4180
        - name: OAUTH2_PROXY_COOKIE_SECURE
          value: 'false'
        - name: OAUTH2_PROXY_EMAIL_DOMAINS
          value: '*'
        - name: OAUTH2_PROXY_OIDC_ISSUER_URL
          value: https://<your-okta-domain>/oauth2/default
        - name: OAUTH2_PROXY_CLIENT_ID
          value: <your-client-id>
        - name: OAUTH2_PROXY_CLIENT_SECRET
          value: <your-client-secret>
        - name: OAUTH2_PROXY_UPSTREAMS
          value: http://localhost:4000
        - name: OAUTH2_PROXY_HTTP_ADDRESS
          value: http://0.0.0.0:4180
        - name: OAUTH2_PROXY_REVERSE_PROXY
          value: 'true'
        - name: OAUTH2_PROXY_SKIP_AUTH_ROUTES
          value: ^/grafana.*
  2. Check Helm Release Status:
    Check the status of your Helm release to see if there are any errors or issues:

    helm status devlake
  3. Check Kubernetes Events:
    Check the Kubernetes events to see if there are any errors related to the oauth2-proxy pod:

    kubectl get events --sort-by=.metadata.creationTimestamp
  4. Check for Pod Creation:
    Ensure that the oauth2-proxy pod is being created. If it is not, there might be an issue with the Helm chart configuration. List all pods to see if there are any pending or failed pods:

    kubectl get pods
  5. Check Helm Chart Values:
    Ensure that the authproxy section is correctly indented and placed in the values.yaml file. Misconfiguration or incorrect indentation can cause the Helm chart to ignore the authproxy settings.

  6. Check Logs:
    If the oauth2-proxy pod is created but not running, check the logs for the pod to see if there are any errors:

    kubectl logs <oauth2-proxy-pod-name>
  7. Redeploy Helm Chart:
    If you made any changes to the values.yaml file, redeploy the Helm chart:

    helm upgrade devlake devlake/devlake --values values.yaml

If you still do not see the oauth2-proxy pod, please provide the output of the helm status devlake and kubectl get events commands, as well as any relevant logs, so I can help you further diagnose the issue.

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

Hi @dosu

We are have forked https://github.com/apache/incubator-devlake repo and developed a new internal custom plugin.
Now how can we generate a new devlake image to include new plugin and deploy it in our own cloud using helm chart.

Thanks in advance.

Copy link

dosubot bot commented Sep 5, 2024

To generate a new DevLake image that includes your custom plugin and deploy it in your own cloud using a Helm chart, follow these steps:

  1. Build the Custom DevLake Image:

    • Create a Dockerfile that includes your custom plugin.
    • Build the Docker image and push it to your Docker registry.

    Example Dockerfile:

    FROM apache/devlake:latest
    COPY your-plugin /path/to/plugin

    Build and push the image:

    docker build -t your-registry/your-devlake:custom .
    docker push your-registry/your-devlake:custom
  2. Deploy Using Helm:

    • Add the DevLake Helm repository and update it.
    • Generate a secure encryption key using a method such as OpenSSL.
    • Install the Helm chart with your custom image.

    Example Helm commands:

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    ENCRYPTION_SECRET=$(openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1)
    helm install devlake devlake/devlake \
      --set lake.image.repository=your-registry/your-devlake \
      --set lake.image.tag=custom \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET

This will deploy DevLake with your custom plugin included in the image. For more detailed instructions and additional configuration options, you can refer to the Apache DevLake Helm Setup documentation.

Additional Configuration Options

  • Custom Timezone:

    helm install devlake devlake/devlake \
      --set lake.image.repository=your-registry/your-devlake \
      --set lake.image.tag=custom \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET \
      --set commonEnvs.TZ="your timezone" \
      --set grafana.env.TZ="your timezone"
  • Set Grafana Admin Password:

    helm install devlake devlake/devlake \
      --set lake.image.repository=your-registry/your-devlake \
      --set lake.image.tag=custom \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET \
      --set grafana.adminPassword=<your password>
  • Deploy with NodePort:

    helm install devlake devlake/devlake \
      --set lake.image.repository=your-registry/your-devlake \
      --set lake.image.tag=custom \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET \
      --set service.uiPort=30000
  • Deploy with Ingress:

    helm install devlake devlake/devlake \
      --set lake.image.repository=your-registry/your-devlake \
      --set lake.image.tag=custom \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET \
      --set "ingress.enabled=true,ingress.hostname=devlake.example.com"

For more detailed deployment scenarios and configurations, refer to the Helm Setup documentation [1][2][3][4].

To continue talking to Dosu, mention @dosu.

@pmallampati-sift
Copy link
Author

Thank you @dosu

Can you also send me details on how to generate a image just for plugin by itself and have the plugin image in helm values file.

Copy link

dosubot bot commented Sep 5, 2024

To generate an image just for a custom plugin and configure the Helm values file to use this plugin image, follow these steps:

  1. Build the Docker Image for Your Custom Plugin:
    Create a Dockerfile for your custom plugin and build the Docker image.

    Example Dockerfile:

    FROM alpine:latest
    COPY your-plugin /path/to/plugin

    Build and push the image:

    docker build -t your-registry/your-custom-plugin:latest .
    docker push your-registry/your-custom-plugin:latest
  2. Configure the Helm Values File to Use the Custom Plugin Image:
    Update the values.yaml file or use the --set flag to specify the custom plugin image.

    Example values.yaml configuration:

    lake:
      image:
        repository: your-registry/your-custom-plugin
        tag: latest
        pullPolicy: Always

    Alternatively, you can set these values directly in the Helm install command:

    helm repo add devlake https://apache.github.io/incubator-devlake-helm-chart
    helm repo update
    ENCRYPTION_SECRET=$(openssl rand -base64 2000 | tr -dc 'A-Z' | fold -w 128 | head -n 1)
    helm install devlake devlake/devlake \
      --set lake.image.repository=your-registry/your-custom-plugin \
      --set lake.image.tag=latest \
      --set lake.image.pullPolicy=Always \
      --set lake.encryptionSecret.secret=$ENCRYPTION_SECRET

This will configure the Helm chart to use your custom plugin image [1][2].

To continue talking to Dosu, mention @dosu.

@nishasati6oct
Copy link

nishasati6oct commented Oct 7, 2024

Hi @dosu
My helm chart looks like below
lake:
initContainers:
- name: update-ca-certificates
image: debian:bullseye
command:
- "sh"
- "-c"
- "apt-get update && apt-get install -y ca-certificates && cp /mnt/root-ca-cert /usr/local/share/ca-certificates/root-ca-cert && update-ca-certificates"
volumeMounts:
- name: root-ca-cert
mountPath: /mnt
volumes:
- name: root-ca-cert
secret:
secretName: ca-cert
envs:
API_TIMEOUT: "120s"
API_RETRY: "3"
API_REQUESTS_PER_HOUR: "10000"
PIPELINE_MAX_PARALLEL: "1"
IN_SECURE_SKIP_VERIFY: "true"

here ca-cert is the SOPS secret for ca-cert.crt data. I am trying to use SSL integration for Azure MySQL.

Error:
Defaulted container "lake" out of: lake, waiting-database-ready (init)
time="2024-10-07T08:12:36Z" level=info msg="no [.env] file, devlake will read configuration from environment, please make sure you have set correct environment variable."
Version: v1.0.1@e061ef2
panic: open /usr/local/share/ca-certificates/root-ca-cert: no such file or directory
Wraps: (2) open /usr/local/share/ca-certificates/root-ca-cert
Wraps: (3) no such file or directory
Error types: (1) *hintdetail.withDetail (2) *fs.PathError (3) syscall.Errno

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/question This issue is a question
Projects
None yet
Development

No branches or pull requests

3 participants