Comments (5)
I agree on storing sensitive data in secrets makes sense. But I don't understand why you want to deploy them separately. In my opinion this makes the deployment more complex.
Could we keep the definition inside the values.yaml but store them in kubernetes secrets? Generally securing sensitive data in the values.yaml must be part of the CI tool, like argocd or flux. Those tools provide mechanisms to secure secrets in values.yaml like sops or vault.
Apart from the passwords you mentioned there are more which should be added to kube-secrets like: geonode.mail.password
, geonode.ldap.bind_password
, rabbitmq.auth.password, rabbitmq.auth.erlangCookie
.
I think most helm deployments handle this the same way as we do in geonode-k8s, therefore users must take care of the passwords themself. I suggest sops here.
from geonode-k8s.
In general, we want to avoid outsourcing secrets when not necessary. Having an in-house CD pipeline is not the standard case IMO. Our current use case is, to version the deployment specific values.yaml
but without the sensitive data in it. Sensitive data, e.g. credentials, are stored in a password safe separately.
Could we keep the definition inside the values.yaml but store them in kubernetes secrets?
We can configure the Secret contents in the values.yaml
:
global:
secrets:
# -- the name of the secret to use
name: demo-secret
# -- The default secret
content: |
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
type: Opaque
data:
# superuser
ADMIN_USERNAME: {{ admin | base64 }}
ADMIN_PASSWORD: {{ geonode | base64 }}
ADMIN_EMAIL: {{ [email protected] | base64 }}
I put it in a dedicated section for now. We can discuss, if we want one Secret for all, or provide one for each deployment.
The values in the Secret's content can be set by the CD pipeline (or the like). Still, I would be able to change the Secret's name to use a different Secret.
We should document both options accordingly:
- Use the
secrets
section if you want to keep sensitive data in thevalues.yaml
(recommend to set them as masked values in a CD setup, or not to version thevalues.yaml
) - Maintain a custom secret (which is not versioned), separated from config version control. This can be created either by hand or by other tools like
kustomize
, then.
SOPS look interesting but requires to throw more tools on the problem. I also had a look at Helm plugins which handle encrypting secrets. However, this makes the toolchain more complicated in IMO, but still we out-source (now encrypted) secrets.
from geonode-k8s.
I have updated the PR #71 but did not added missing credentials so far (geonode.mail.password
, geonode.ldap.bind_password
, rabbitmq.auth.password
, rabbitmq.auth.erlangCookie
). Please have a first look.
from geonode-k8s.
@mwallschlaeger I marked the PR as Draft for now.
However, I revised the status and found some bugs which (I hope) could fix in the last commit. However, I have to update the minikube values to match the changes in the values.yaml
and check the external database config still.
from geonode-k8s.
@mwallschlaeger minikube values are in line with values.yaml
. I also had a look at the external database config and fixed the username_email
default setting in the values.yaml
.
from geonode-k8s.
Related Issues (20)
- Task: Prepare release 1.0.10
- Task: use official geonode docker images
- Bug: Database connection issue when using postgres-operator HOT 1
- Feature: Add ImagePullPolicy to all container
- Feature: append code to settings.py
- Feature: Allow to set Access-Control-Allow-Credentials to true in NGINX HOT 2
- Bug: Restore of geonode backup is not working HOT 4
- Feature: properly setup liveness and readyness probes for all containers
- Bug: Error in tasks.py when initiating GeoNode container
- Feature: load alternative metadata.xml template
- Bug: deployment not working when using an external postgis db with no SSL configured
- Task: Document changes of version 1.1.0
- Task: Prepare release 1.1.1
- Discussion: Evaluate geoserver-cloud integration HOT 13
- Task: Upgrade default versions for GeoServer and GeoServer_data HOT 2
- Feature: add optional geoserver-geonode autosync feature
- Bug: Dockerize installation in geonode container init is not working HOT 1
- Task: support GeoNode 4.3
- Feature: refector nginx deployment HOT 2
- Task: Bump PostrgesOperator version HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geonode-k8s.