5 Tips to Safely Use Credentials in Your Python Project
Вставка
- Опубліковано 20 чер 2024
- In this video, I'll share 5 simple tips to help keep your Python credentials safe and fix problems quickly if they occur.
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
💻 ArjanCodes Blog: www.arjancodes.com/blog
✍🏻 Take a quiz on this topic: www.learntail.com/quiz/fwotcw
Try Learntail for FREE ➡️ www.learntail.com/
🎓 Courses:
The Software Designer Mindset: www.arjancodes.com/mindset
The Software Architect Mindset: Pre-register now! www.arjancodes.com/architect
Next Level Python: Become a Python Expert: www.arjancodes.com/next-level...
The 30-Day Design Challenge: www.arjancodes.com/30ddc
🛒 GEAR & RECOMMENDED BOOKS: kit.co/arjancodes.
👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!
Social channels:
💬 Discord: discord.arjan.codes
🐦Twitter: / arjancodes
🌍LinkedIn: / arjancodes
🕵Facebook: / arjancodes
📱Instagram: / arjancodes
♪ Tiktok: / arjancodes
👀 Code reviewers:
- Yoriz
- Ryan Laursen
- Dale Hagglund
- Kit Hygh
- Alexander Milden
- Bean
🎥 Video edited by Mark Bacskai: / bacskaimark
🔖 Chapters:
0:00 Intro
0:31 Tip 1: Use Environment variables
2:24 Tip 2: Keep commits small
3:08 Tip 3: Follow the least privilege principle
4:00 Tip 4: Don’t share credentials in plain text
4:25 Tip 5: Use credential scanning tools
5:02 Final thoughts
#arjancodes #softwaredesign #python
DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!
👷 Join the FREE Code Diagnosis Workshop to help you review code more effectively using my 3-Factor Diagnosis Framework: www.arjancodes.com/diagnosis
Hey Arjan, thank you for your work from Spain. Would be great if you create a video with your top python books "to improve your python skills to another level", thank you!
Great tips, thanks! For item 4. "Don't share credentials in plain text". If you're developing for AWS, then AWS Secrets Manager is a good choice.
Pro Tip: Use a secrets manager, like 1 password CLI that can dynamically embed your secrets from your vault into the env. It also allows you to share the secrets securely with team, and rotate them centrally.
arjan out here fleeced out new hoodie i gotta step it up
Instead of using the dotenv package I rather like using direnv configured with `load_dotenv = true`. That way the project becomes agnostic of any particular package populating environment variables from `.env`. The project receives all the variables the same way, but without having to import anything extra. This technique works for any project in any language, even though for a specific language there is no dotenv package provided.
Hey Arjan, thank you for your work from Spain. Would be great if you create a video with your top python books "to improve your python skills to another level", thank you!
Thanks a lot! Nice tips, everybody should do so.
Glad the content was useful!
The 'keyring' library is also very handy to store credentials using the OS's built-in credential manager in a structured way.
What if I'm making executables with pyinstaller?
A few collegues of mine discussed using a centralized service to store credetials for multiple software projects. Ideally including monitoring for any credetials that involve external API-services. Any suggestions?
Despite the hints are appliable to any repository you can use, that's one of the reasons why I (and my teams) use our self-hosted Gitea servers for private projects (and similar ones for job's). Gitea is practically identical to github as far as I use it. I think that github is only for public sharing tested, non private and/or thoroughfully reviewed things.
You can also use tools like 'git filter-branch' and 'git filter-repo' (recommended) to remove any secrets from your git history. The downside is that you have to force push afterwards since you're changing the history.
Several companies that I have worked at use Vault as the de facto way of sharing credentials with services running in production. I would say this is probably more secure than all of the ways described in this video.
Agree. But then, how did you store the Vault token? :)
@@nierodwirski3515 you can store the Vault token using any of the methods above or even plain text. The way it works if properly set up is that the Vault token by itself won’t get you the credentials from Vault. You will need to pass the Vault token + some ID (E.g. Mesos Task ID, Kubernetes Job ID, etc.) and your vault service will validate that the job ID belongs to an active job running on your cluster before responding with the creds your service requested.
Nuttige tips!!
Graag gedaan ☺️
Second 😂 ! Thanks man for your amazing content. From a teacher, you are a good example of someone who knows the art of teaching. Good luck
Thank you so much for the kind words!
If server is hacked, attacker can dump environment variables. How to defend against this ?
I think once you get your server hacked, it's mostly game over anyway.
My advice would be to secure your server, and at least encrypt your keys before storing them.
That will at least slow attackers down, but if they can dump memory, you're not going to be able to defend much…
@@amarasa2567That's not healthy to think like this about the problem. You should always maintain multiple layers and barriers of defense.
@@anonapache oh, definitely, but that only slows attackers down, that doesn't make it impossible to get your keys.
And once again, if attackers can dump memory, it's all over anyway, since they have to be somewhere in memory at some point...
The point is making it too complicated to get to this point to be worthwhile.
Defence in depth also adds cost, performance, and usability constraints (if not outright penalties).
Yeah it's required, but there's always a tradeoff
If your server gets hacked, I don’t think environment variables are the biggest issue…
If the server gets hacked, be sure to be alerted, and just change all of your credentials
I think that the people who are likely to commit private key files are also the same kind of people who would create a .env file and not add a gitignore rule for it.
That’s way Arjan tells them to add the .env file to the .gitignore
impossible to get any variable, still fighting on this crap since three days and it systematically returns me none
First ❤
this weird convention of making env definitions hidden drives me crazy. I have no idea where it comes from, to me it's completely illogical
Do you plan on using another VSCode theme ?
The default one is pretty lame if you ask me, it does not have enough colors to differentiate the different types of words in a Python script.
I suggest you to use Atom Dark Pro, as it’s close enough to the original theme, but with way more colors for the scripts.
I can understand that you don’t want beginners to be disturbed, but I think that past a certain point, everyone has a custom theme, and it might not be a good idea to accustom beginners to the bad default theme
os.environ[key]/os.environ.get() is faster than os.getenv() and is also a good practice, because it lowers the chances of people thinking they should in turn use the (broken) os.setenv() when they need to set environment variables.
Thanks for the tip