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
Many credentials are being used in the deployments like username and password/identity secrets for peers, orderers, CAs, etc. Along with passing these values as plaintext in helm values file, there should be an option to read these values from kubernetes secrets (like many vendor helm charts offer).
The creation of these secrets is up to the user, weather they create them manually or via some operator like External Secrets Operator.
This will directly help towards the "Manage secrets with secrets management services like Vault, AWS Secrets manager, etc" feature goal.
Example:
The Values file will look something like this:
identity_name: xyzidentity_secret: abc# Name of the secret resource to take the above two values from. The keys have to be exactly same as above.identityCredsFromSecret: identity_secret #<--- This is the name of the secret resource where the identity_name and identity_secret is mentioned
The text was updated successfully, but these errors were encountered:
@runitmisra Use a single secret for all identity registration under a CA rather than creating individual secrets for every identities. Otherwise we will end-up with 100+ secrets for the TLSCA.
@jithindevasia can't we dynamically generate the secrets and it's value. (From a security standpoint let all identities be using a unique secret)
Managing/Creating secrets from falcon will lead us to use any cli actions like kubectl or something which will be platform dependent then. I prefer to leave the secret creation/management outside falcon. So people can have their own way to manage secrets.
Many credentials are being used in the deployments like username and password/identity secrets for peers, orderers, CAs, etc. Along with passing these values as plaintext in helm values file, there should be an option to read these values from kubernetes secrets (like many vendor helm charts offer).
The creation of these secrets is up to the user, weather they create them manually or via some operator like External Secrets Operator.
This will directly help towards the "Manage secrets with secrets management services like Vault, AWS Secrets manager, etc" feature goal.
Example:
The Values file will look something like this:
The text was updated successfully, but these errors were encountered: