I've read a lot about why it's best to store sensitive data in Secrets rather than ConfigMaps, which makes sense. But I'm curious about taking this to the extreme: could we just use Secrets for everything and not bother with ConfigMaps anymore? Are there any reasons why that might not be a good idea?
5 Answers
Permissions play a big role here too. You might want to let some users view app configurations while restricting access to sensitive data in Secrets. Using both can help maintain better security and clarity in RBAC setups.
Using ConfigMaps makes it easier to edit them on the fly without worrying about base64 encoding issues. Plus, they allow for a more organized structure, so your team can quickly identify what configurations are being used without sifting through sensitive data.
It's really a matter of design and preference. While you could use Secrets for everything, it might introduce unnecessary complexity, especially when you could just use ConfigMaps for regular configuration that isn’t sensitive.
There’s no technical limitation preventing you from using only Secrets. However, with some GitOps setups, it's easier to track changes to ConfigMaps since they're generally not encoded like Secrets are. Plus, using ConfigMaps allows for plain text inputs, which can make things simpler.
True! The stringData field in Secrets lets you add plain text without base64 encoding.
Ultimately, it's about keeping things clear and organized. You can choose to mix them or rely on one, but having both allows for a natural separation of sensitive and non-sensitive configurations. Also, ConfigMaps offer automatic updates when changes occur, which is a nice perk you miss out on with Secrets.
Definitely! It's about controlling who can see what, especially if you have a larger team.