DevOps Principles & Best Practices by Kayan Azimov
One of the issues when using personal secrets in vault is the admin/root user being able to access everything in vault, thus making usage of personal secret less secure.
In order to protect the personal secret from root/admin access we can however keep secret in an encrypted way, using private key, gpg, or just a password. Below is an example how to protect the secret with a password.
Comments closed
Today I will show you how to use vault for your personal secrets. Normally you would auth and get access to some path in vault where everyone in your team have access too, but in some cases you may want to use vault for your own secrets as well, i.e for storing passphrase for the ssh private key or email or something similar.
So here is a list of commands that needs to be run, first as an admin to set up auth and policies, and then as a user, auth and read/write secrets.
Create a policy that allows actions under ones identity:
cat <<EOF | vault policy write identity -
path "secret/data/{{identity.entity.id}}/*" {
capabilities = ["create", "read", "update", "delete"]
}
EOF
Comments closed 
Quite often especially on corporate networks, once connected to company VPN, all your traffic starts going via your company VPN, meaning – they watching what you do.
Most people may not even suspect that but it is quite simple to find out.
So I am gonna show how to do that on Mac with few commands everyone can run.
OK, lets check out routing tables when connected to VPN:
netstat -nr | grep '0/1\' 0/1 10.225.222.129 UGSc 70 0 utun3 default 192.168.0.1 UGSc 12 11 en0 128.0/1 10.225.222.129 UGSc 0 0 utun3Comments closed
Sometimes you have this networking issue when a new network needs to be whitelisted in order to have access to some other network.
In some cases we could use a workaround given target network is accessible via third party network:
A -> no access -> B A -> access -> C C -> access -> B A -> C -> BComments closed
I just ran my tool to get the-most-demanded-devops-skills-stats and noticed a small (or may be not that small) change:
jobstats -c -2 | head -20 azure 212 aws 194 kubernetes 66 terraform 56 gcp 55 git 48 docker 43 python 40 ci/cd 30 jenkins 28 linux 18 bash 10 ansible 10 scripting 9 unix 3 puppet 3 groovy 2 elk 2 chef 2 zabbix 1Comments closed
I came across this amazing way of testing if I could reach a port on the host, when literally nothing I tried was available:
vagrant@ ~ () $ echo hi | nc -l -p 8089 & [1] 13651 vagrant@ ~ () $ cat < /dev/tcp/127.0.0.1/8089 hi [1]+ Done echo hi | nc -l -p 8089 vagrant@ ~ () $ vagrant@ ~ () $ cat < /dev/tcp/127.0.0.1/8089 -bash: connect: Connection refused -bash: /dev/tcp/127.0.0.1/8089: Connection refusedComments closed