You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In AWS CloudFormation CDK we do not want to expose the authEncryptSecretKey in CloudFormation when we instantiate the values yaml in code (this is available in AWS CloudFormation webpage and visible by many with only read-only permissions).
Right now in my code I have (which is exposed both in repos and in cloudformation):
Helm Chart will create a Secret named "lakefs" (actually lakefs.fullname) with that value and use it from lakeFS pods. It would be great if users could provide "authEncryptSecretRef" in order for LakeFS to use a user-provided secret (which user can register beforehand using more CDK-friendly mechanisms).
The current approach is still the most developer-friendly for many deployment methods so its still valid, but for AWS CDK its not "valid" in my opinion.
The text was updated successfully, but these errors were encountered:
I'm less familiar withe AWS CloudFormation CDK capabilities.
As a temporary workaround I suggest to check any secerts mechanism you have access to load the secret value and render values.yaml for the chart with the value and not hard coded it into the code itself.
Will look into possible alternatives (possible PR associated) to this issue as part of the chart.
Hi
In AWS CloudFormation CDK we do not want to expose the authEncryptSecretKey in CloudFormation when we instantiate the values yaml in code (this is available in AWS CloudFormation webpage and visible by many with only read-only permissions).
Right now in my code I have (which is exposed both in repos and in cloudformation):
Helm Chart will create a Secret named "lakefs" (actually lakefs.fullname) with that value and use it from lakeFS pods. It would be great if users could provide "authEncryptSecretRef" in order for LakeFS to use a user-provided secret (which user can register beforehand using more CDK-friendly mechanisms).
The current approach is still the most developer-friendly for many deployment methods so its still valid, but for AWS CDK its not "valid" in my opinion.
The text was updated successfully, but these errors were encountered: