search

apache / incubator-devlake

Apache DevLake is an open-source dev data platform to ingest, analyze, and visualize the fragmented data from DevOps tools, extracting insights for engineering excellence, developer experience, and community growth.
https://devlake.apache.org/
Apache License 2.0
2.55k stars 508 forks source link

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

Open pmallampati-sift opened 3 weeks ago

pmallampati-sift commented 3 weeks ago

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.

dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

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""
dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

@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"
dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

@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.

dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

@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

dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

@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.
dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

@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 https://github.com/apache/incubator-devlake/issues/7928#issuecomment-2300787106

`lake: initContainers:

dosubot[bot] commented 3 weeks ago

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 commented 3 weeks ago

@dosu

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

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
dosubot[bot] commented 3 weeks ago

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 commented 2 weeks ago

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

pmallampati-sift commented 2 weeks ago

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 commented 2 weeks ago

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

dosubot[bot] commented 2 weeks ago

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 commented 2 weeks ago

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

dosubot[bot] commented 2 weeks ago

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 commented 2 weeks ago

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

dosubot[bot] commented 2 weeks ago

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 commented 2 weeks ago

@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...?

dosubot[bot] commented 2 weeks ago

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 commented 2 weeks ago

@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
dosubot[bot] commented 2 weeks ago

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 commented 1 week ago

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.

dosubot[bot] commented 1 week ago

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

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 commented 1 week ago

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.

dosubot[bot] commented 1 week ago

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.