salmon-refrigerator-32115
08/04/2023, 11:21 PMos.getenv("FLYTE_INTERNAL_TASK_DOMAIN", "dev")
However, it’s not telling the EKS environment.tall-lock-23197
big-magician-84523
08/08/2023, 12:29 PMsalmon-refrigerator-32115
08/08/2023, 5:14 PMsalmon-refrigerator-32115
08/09/2023, 4:43 PMflyte:
enabled: true
values:
secrets:
adminOauthClientCredentials:
enabled: false
clientId: xxx
userSettings:
accountNumber: "123"
accountRegion: "us-east-1"
environment: "development"
certificateArn: "arn:aws:acm:us-east-1:123:certificate/yyy"
This is to override the values-eks.yaml.
I think this is EKS cluster certificate.
I am trying to create certificate for stage and production envs.
And for that the cluster engineering is asking for the git repo that has been used to create the existing certificate.
Do you know if that certificate was created using a git repo? If so, do you know how I can find that repo?
Thanks.
P.S. the domain for the certificate in the Bolt Dev AWS account is flyte.example.org.big-magician-84523
08/10/2023, 8:02 PMsalmon-refrigerator-32115
08/10/2023, 8:57 PMbig-magician-84523
08/11/2023, 12:13 PMsalmon-refrigerator-32115
08/23/2023, 5:40 PMcommon:
### This secret needs to exist in the flyte namespace prior.
databaseSecret:
name: flyte-postgresql-manualcopy
In the example values from Flyte:
databaseSecret:
name: db-pass
secretManifest:
# -- Leave it empty if your secret already exists
# Else you can create your own secret object. You can use Kubernetes secrets, else you can configure external secrets
# For external secrets please install Necessary dependencies, like, of your choice
# - <https://github.com/hashicorp/vault>
# - <https://github.com/godaddy/kubernetes-external-secrets>
apiVersion: v1
kind: Secret
metadata:
name: db-pass
type: Opaque
stringData:
# -- If using plain text you can provide the password here
pass.txt: "{{ .Values.userSettings.dbPassword }}"
2. flyte-secret-auth, how was this secret created? and how was the additional FLYTE_DATABRICKS_API_TOKEN got added?
kubectl get secret -n flyte flyte-secret-auth -o json
{
"apiVersion": "v1",
"data": {
"FLYTE_DATABRICKS_API_TOKEN": "ZGFwaTkwZWUzMzkzMjA2YzdmNDk2NmJjYWQwZjM4ODdiOTli",
"client_secret": "Zm9vYmFyCg=="
},
"kind": "Secret",
The example values:
secrets:
adminOauthClientCredentials:
# -- If enabled is true, helm will create and manage `flyte-secret-auth` and populate it with `clientSecret`.
# If enabled is false, it's up to the user to create `flyte-secret-auth` as described in
# <https://docs.flyte.org/en/latest/deployment/cluster_config/auth_setup.html#oauth2-authorization-server>
enabled: true
clientSecret: foobar
clientId: flytepropeller
If it’s created automatically by Flyte as described above (setting enabled: true) , then what was the decrypted clientSecret value?
In the dev cluster’s overriding values:
secrets:
adminOauthClientCredentials:
enabled: false
clientId: 0oa3op8ubeMDXDCcC697
How come the clientId got changed from the default value ‘flytepropeller’?
Thank you very much if you can provide any useful history of the secrets!