Comments (6)
@nickburgin We're planning on making a change that will make it so the operator can process DopplerSecret resources in any namespace. The only caveat will be that they'll have to use a
tokenSecret
andmanagedSecret
that's in the same namespace as the DopplerSecret in those cases. The behavior as it exists today would also be possible. Would this work for you?
Yes, that would work perfectly
from kubernetes-operator.
@nickburgin The reason we don't have an upper-snake
option is because that's the format ALL secrets in Doppler are stored in by default. You can't add a secret to Doppler without it being in upper-snake
format currently. As such, when you create a managed secret, all the secret keys in that k8s secret will already be in upper-snake
, so no transformation is required. Could you provide me with more information about what you're seeing that's different from this behavior?
from kubernetes-operator.
Also, as an aside, if you're using an up-to-date operator, then DopplerSecret CRDs need to be created in the operator namespace (doppler-operator-system
by default) so you'd need to specify that namespace in the metadata
section:
apiVersion: secrets.doppler.com/v1alpha1
kind: DopplerSecret
metadata:
name: oauth2-secrets
namespace: doppler-operator-system
spec:
tokenSecret:
name: doppler-service-token
managedSecret:
name: oauth2-secrets
The tokenSecret
will look in the doppler-operator-system
automatically by default if no namespace is specified and the managedSecret
will be created in the default
namespace by default if no namespace is specified. The tokenSecret
and managedSecret
can be in any namespace (as long as you specify it), but the CRD itself must exist in the same namespace as the operator currently and that's done by specifying the namespace in the metadata
section as shown above.
from kubernetes-operator.
After some further investigation, I realized that I had a stale sealedSecret object creating a secret with the same name. After cleaning that up, I am indeed observing that the DopplerSecret
object in the target namespace (not doppler-operator-system
) is not working (as you assert that it shouldn't above).
I have now created a working example by placing the DopplerSecret
object in the doppler-operator-system
namespace.
apiVersion: secrets.doppler.com/v1alpha1
kind: DopplerSecret
metadata:
name: platform-demo-staging-oauth2-secrets # this is already pretty long, we have other examples while may be quite a bit longer
namespace: doppler-operator-system # don't love it
spec:
tokenSecret:
name: doppler-service-token
namespace: platform-demo-staging # if the dopper secret could be in any namespace, the default here should be the same namespace as where the doppler secret is located. I can understand wanting to default to the dopler-operator-system namespace when using a service account token though.
managedSecret:
name: oauth2-secrets
namespace: platform-demo-staging
This is not how the behaviour is documented:
Note: While these resources can be created in any namespace, it is recommended that you create your Doppler Token Secret and DopplerSecret inside the doppler-operator-system namespace to prevent unauthorized access. The managed secret should be namespaced with the deployments which will use the secret.
Storing everything in the doppler-operator-system
namespace would be a nightmare for us; we use a small number of clusters with a large number of deployed services in each cluster, each service is resident in it's own namespace, and quite a few of them will have overlapping secret names that will map to different doppler projects and/or configs. Is there a limitation on the length of a DopplerSecret name? We would also have to reduce some built in safety checks in our tooling to allow manifests to deploy objects to multiple namespaces, don't love the idea...
In this experiment, I have set up the terraform module that manages any given kubernetes namespace to provision a service token for the target doppler config, and store the token in a kubernetes secret object within that namespace, this feels better than provisioning and storing a single service account token for the whole cluster (which would have to have global read over all projects in our whole doppler workspace), which would be the obvious thing to do if all DopplerSecrets are to be stored in the same namespace.
Security wise in our clusters, the few people who can access the contents of that secret (or any secret in the namespace), can also get a shell in any pod in the namespace and inspect the environment directly, so there isn't any material advantage to hiding portions of that services config away in another namespace, just needless confusion and additional cognitive load on our developers. And the service token won't give them access to anything beyond what they could access anyway.
Further to this, I don't see how any part of the DopplerSecret
could be considered sensitive enough to warrant placing it in a more controlled namespace than the token it requires or the secrets it manages, it's just some basic metadata.
Given how other kubernetes CRDs behave (contour, sealed-secrets and cert-manager to name a few that don't force objects to be created in a specific namespace), and the intent of the kubernetes developers (CRDs extend the behaviour of a cluster, and a namespace can be considered a virtual cluster - object definitions in a namespace can access that extended behavior through the newly defined resources, but should be able to remain isolated from other namespaces), it doesn't feel right (to me anyway) that Doppler is forcing certain non-idiomatic implementation details upon its users.
My suggestion would be to document your recommended approach (as you have done), but allow the people building cloud infrastructure to make their own decisions on how they manage security (which you have recently taken away by the sounds of it) as there are many ways to approach this, and the best option depends on the specific requirements of a particular team or organisation.
from kubernetes-operator.
@nickburgin We're planning on making a change that will make it so the operator can process DopplerSecret resources in any namespace. The only caveat will be that they'll have to use a tokenSecret
and managedSecret
that's in the same namespace as the DopplerSecret in those cases. The behavior as it exists today would also be possible. Would this work for you?
from kubernetes-operator.
Also, as an aside, I've updated the docs to clarify that the DopplerSecret must be in the same namespace as the operator (for now anyways).
from kubernetes-operator.
Related Issues (20)
- Random failure publishing new secrets on changes HOT 4
- Allow DopplerSecret to be deployed to other namespaces HOT 1
- recommended.yaml not available in latest HOT 4
- GCP GKE INFO logs are showing ERROR HOT 5
- Feature request: Service Account support HOT 1
- RabbitMQ - default-user-credential-updater using Doppler Secrets HOT 3
- Is there an option to automatically create a new config if it's not found? HOT 1
- Strange double-deployment when doing helm deploy HOT 10
- "Cannot change existing managed secret type from Opaque to ." after upgrading to 1.4.0 HOT 3
- Manage CRDs via Helm HOT 1
- Configure resources for all containers HOT 1
- How to configure a "master token secret" HOT 6
- [Kubernetes] imagePullSecrets: unable to deploy HOT 2
- Set Loglevel HOT 4
- Reconcile algorithm overuses the Doppler API HOT 2
- Can't create managed secret for a project's root config HOT 1
- The operator should allow arbitrary string->string mappings for secrets HOT 2
- Helm Chart dependency `kube-rbac-proxy` deprecation warning HOT 1
- Support custom labels on created Secret HOT 3
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 kubernetes-operator.