protoPayload.methodName="google.container.v1.ClusterManager.CreateCluster"All GKE cluster logs
resource.type="gke_cluster"Access transparency logs
logName="projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com%2Faccess_transparency"OR
jsonPayload.@type="type.googleapis.com/google.cloud.audit.TransparencyLog"
nmap --script ssl-enum-ciphers -p 443 www.example.com
kubectl get constrainttemplates -l="configmanagement.gke.io/configmanagement=config-management"Get the status of a particular constraint, including logged violations:
kubectl get k8sallowedrepos.constraints.gatekeeper.sh repo-is-gcrGet the policy controller logs:
kubectl logs -n gatekeeper-system -l gatekeeper.sh/system=yes
With docker changing its license and the general problem of running a super privileged daemon, I've been looking for alternatives. Here's what I've found to work.
Gcrane for interacting with registries:
go install github.com/google/go-containerregistry/cmd/gcrane@latest
export PATH="${HOME}/go/bin:$PATH"
gcrane pull ubuntu ubuntu.tar
gcrane push ubuntu.tar gcr.io/my-project/ubuntu
gcrane cp ubuntu gcr.io/my-project/ubuntu
Podman for building and pushing
sudo apt-get install podmanIf you get this warning:
Reading allowed ID mappings: reading subuid mappings for user "${USER}" and subgid mappings for group "${USER}": no subuid ranges found for user "${USER}" in /etc/subuidYou need to add some UIDs:
sudo usermod --add-subuids ${start_uid:=100000}-$(( ${start_uid:=100000} + "65535" )) $(whoami)
sudo usermod --add-subgids ${start_gid:=100000}-$(( ${start_gid:=100000} + "65535" )) $(whoami)
Then you can use it:
podman build -t ${IMG}:${TAG} .
# Auth to an artifact registry repo
gcloud auth print-access-token | podman login -u oauth2accesstoken --password-stdin ${REGION}-docker.pkg.dev
podman push ${REGION}-docker.pkg.dev/${PROJECT}/${REPO}/${IMG}:${TAG}
# Run a container
podman run --rm -it alpine:latest /bin/sh
Sadly GNOME seems to be missing (or has removed) options to disable all of the annoying stuff it's doing.
To disable the stupid workspace switching animation you have to install an entire extension. I installed this one directly from github, the code is tiny, you can read it.
To turn off the hotcorner that I continually accidentally hit there is apparently no longer a UI option, but running:
gsettings set org.gnome.desktop.interface enable-hot-corners false
worked.
Annoyingly the UI control you do have is not anywhere intuitive like with GNOME in the name. It's in "tweaks" and "extensions". Tweaks is where you can adjust font size, Extensions is where the workspace switching toggle shows up and also where you can disable the applications menu.
There are no logs available in the app, but there's quite a lot available from the diagnostic report API. It's in protobuf format, so someone wrote a handy little parser.
go get github.com/benmanns/onhub/cmd/onhubdump ~/go/bin/onhubdump http://192.168.86.1/api/v1/diagnostic-report > logs.json $ jq 'keys' logs.json [ "commandOutputs", "fileLengths", "files", "networkConfig", "stormVersion", "unixTime", "unknown1", "unknownPairs", "version", "wanInfo", "whirlwindVersion" ] $ jq -r '.files[].path' logs.json /etc/lsb-release /etc/resolv.conf /proc/net/arp /proc/slabinfo /proc/meminfo /sys/firmware/log /var/log/debug-log/debug-log /var/log/boot.log /var/log/net.log /var/log/update_engine/update_engine.20200102-000001 /var/log/update_engine/update_engine.20190102-000001 /var/lib/ap/monitor/wan_idle_usage /var/lib/ap/monitor/child_idle_usage /var/lib/ap/health-monitor/wan_connectivity_history /var/log/ap_fresh_dns_messages /var/log/ap_https_server_messages /var/log/critical_events.log /var/log/messages # Get /var/log/messages content: $ jq -r '.files[17].content' logs.json | less
TIL about DNS CNAME "flattening" which is a cloudflare feature that allows you to put a CNAME at the domain root: something that is actually not allowed by the DNS RFC spec.
Why does that matter? I was helping a nonprofit who is using a website hosting company, but the nonprofit has its own domain name. The hosting company tells them to "create a CNAME pointing at blahblah.somehosting.com" which works great, I created "www.example.com" as a CNAME pointing to the hosting address.
But what about the "naked" domain? i.e. if I type example.com like a normal person instead of www.example.com it doesn't resolve, and I don't have anywhere to point it. The cloudflare solution as above is to allow you to do something non-RFC compliant and also put a CNAME record at the root.
Google domains takes a different approach, to solve the problem you can create a subdomain forward for "@" and point it at your www.example.com target. With "forward path" enabled on the entry the URLs will also be preserved through the redirect.
Under the hood Google creates A records for the root domain, so a request for the root domain will resolve to a Google service that then resolves your www.example.com CNAME, establishes a HTTP session with the requester and issues the requesting browser a 301/302 redirect.
/usr/bin/docker run --rm robertcsapo/speedtest --csv >> speedtest.csvAssuming you run docker passwordless (actually a bad idea for security) you can then add this to your crontab. You may want to consider running it outside of when you need your network bandwidth the most:
0 1 * * * /usr/bin/docker run --rm robertcsapo/speedtest --csv >> /home/myuser/speedtest.csvTo do this with better security don't run docker passwordless, but allow sudo to run this specific command, where the userid 12345 is your userid that you can get by running 'id'. This will allow you to run this command as a non-root user:
myuser ALL=(ALL) NOPASSWD: /usr/bin/docker run -u 12345 --rm robertcsapo/speedtest --csvAnd then in your cron put:
0 1 * * * sudo /usr/bin/docker run -u 12345 --rm robertcsapo/speedtest --csv >> /home/me/speedtest.csv
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yamlWe can see this creates configs and constrainttemplates CRDs:
$ kubectl api-resources | grep gatekeeper.sh configs config.gatekeeper.sh true Config constrainttemplates templates.gatekeeper.sh false ConstraintTemplateThe constraints based off the constraintemplates will themselves will be their own CRDs. In the gatekeeper-system namespace we have the controller manager and webhook that will serve the validating webhook requests from the API server:
$ kubectl get all -n gatekeeper-system NAME READY STATUS RESTARTS AGE pod/gatekeeper-controller-manager-77ff8cc995-sh8xq 1/1 Running 1 6d21h NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/gatekeeper-webhook-service ClusterIP 10.0.5.112The next step is creating constraint templates, here's one that denies all Ingress:443/TCP 6d21h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/gatekeeper-controller-manager 1/1 1 1 6d21h NAME DESIRED CURRENT READY AGE replicaset.apps/gatekeeper-controller-manager-77ff8cc995 1 1 1 6d21h
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8snoexternalservices
spec:
crd:
spec:
names:
kind: K8sNoExternalServices
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8snoexternalservices
violation[{"msg": msg}] {
input.review.kind.kind == "Ingress"
re_match("^(extensions|networking.k8s.io)$", input.review.kind.group)
msg := sprintf("No external service exposure is allowed via ingress: %v", [input.review.object.metadata.name])
}
But how did we know that it was input.review.kind.kind? That's pretty unintuitive. Turns out it's because that's the structure of the object passed to the authenticating webhook. We can see this by creating a constraint template that just blocks everything and logs the full object:
$ cat template.yaml
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8sdebugtemplate
spec:
crd:
spec:
names:
kind: K8sDebugTemplate
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package debugging
violation[{"msg": msg}] {
msg := sprintf("Review object: %v", [input.review])
}
$ kubectl apply -f template.yaml
And then apply that to ingress objects:
$ cat constraint.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sDebugTemplate
metadata:
name: debuggingdeny
spec:
match:
kinds:
- apiGroups: ["extensions", "networking.k8s.io"]
kinds: ["Ingress"]
$ kubectl apply -f constraint.yaml
$ kubectl api-resources --api-group=constraints.gatekeeper.sh
NAME SHORTNAMES APIGROUP NAMESPACED KIND
k8sdebugtemplate constraints.gatekeeper.sh false K8sDebugTemplate
Then when we create any ingress we get a full object logged:
$ cat basic-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: basic-ingress
namespace: frontend
spec:
backend:
serviceName: web
servicePort: 8080
If we patch an existing object we get to see old object filled out too:
$ kubectl patch -f basic-ingress.yaml -p '{"spec":{"backend":{"servicePort":8081}}}' 2>&1 | sed s'/): admission webhook.*//' | sed s'/.* Review object: //' | jq
{
"operation": "UPDATE",
"userInfo": {
"username": "me@example.com",
"groups": [
"system:authenticated"
],
"extra": {
"user-assertion.cloud.google.com": [
"XX=="
]
}
},
"object": {
"kind": "Ingress",
"apiVersion": "extensions/v1beta1",
"metadata": {
"annotations": {
"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"extensions/v1beta1\",\"kind\":\"Ingress\",\"metadata\":{\"annotations\":{},\"name\":\"basic-ingress\",\"namespace\":\"frontend\"},\"spec\":{\"backend\":{\"serviceName\":\"web\",\"servicePort\":8080}}}\n"
},
"finalizers": [
"finalizers.gatekeeper.sh/sync"
],
"name": "basic-ingress",
"namespace": "frontend",
"uid": "403d4a8f-2db0-11ea-828b-42010a80004c",
"resourceVersion": "2135434",
"generation": 2,
"creationTimestamp": "2020-01-02T22:36:00Z"
},
"spec": {
"backend": {
"serviceName": "web",
"servicePort": 8081
}
},
"status": {
"loadBalancer": {
"ingress": [
{
"ip": "1.2.3.4"
}
]
}
}
},
"oldObject": {
"kind": "Ingress",
"apiVersion": "extensions/v1beta1",
"metadata": {
"name": "basic-ingress",
"namespace": "frontend",
"uid": "403d4a8f-2db0-11ea-828b-42010a80004c",
"resourceVersion": "2135434",
"generation": 1,
"creationTimestamp": "2020-01-02T22:36:00Z",
"annotations": {
"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"extensions/v1beta1\",\"kind\":\"Ingress\",\"metadata\":{\"annotations\":{},\"name\":\"basic-ingress\",\"namespace\":\"frontend\"},\"spec\":{\"backend\":{\"serviceName\":\"web\",\"servicePort\":8080}}}\n"
},
"finalizers": [
"finalizers.gatekeeper.sh/sync"
]
},
"spec": {
"backend": {
"serviceName": "web",
"servicePort": 8080
}
},
"status": {
"loadBalancer": {
"ingress": [
{
"ip": "1.2.3.4"
}
]
}
}
},
"uid": "6410973b-2db1-11ea-828b-42010a80004c",
"kind": {
"group": "extensions",
"version": "v1beta1",
"kind": "Ingress"
},
"resource": {
"group": "extensions",
"version": "v1beta1",
"resource": "ingresses"
},
"options": null,
"_unstable": {
"namespace": {
"kind": "Namespace",
"apiVersion": "v1",
"metadata": {
"creationTimestamp": "2019-12-26T23:29:47Z",
"annotations": {
"kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"Namespace\",\"metadata\":{\"annotations\":{},\"name\":\"frontend\"}}\n"
},
"name": "frontend",
"selfLink": "/api/v1/namespaces/frontend",
"uid": "9a96616e-2837-11ea-8e60-42010a80017b",
"resourceVersion": "33039"
},
"spec": {
"finalizers": [
"kubernetes"
]
},
"status": {
"phase": "Active"
}
}
},
"name": "basic-ingress",
"namespace": "frontend",
"dryRun": false
}
We can clean up the debugging rule by deleting the constraint:
kubectl delete k8sdebugtemplate.constraints.gatekeeper.sh debuggingdenyIn terms of policy writing you can test individual policies like this:
$ docker run -v /Users/gcastle/git/gatekeeper/library/general/uniqueingresshost:/tests openpolicyagent/opa test /tests/src.rego /tests/src_test.rego PASS: 12/12The current testing relies on rego assertions as tests, which is a bit of a PITA when you need to create a lot of test permutations on objects because you need to re-create the admission object above to some extent. It's also not super obvious what passing and failing are, it could do with a higher-level test framework:
kustomize build templates | kubectl apply -f -
# Put a quote in front of the first alphabetic character on each line s!\([a-z]\)!"\1!c
sudo tcpdump -i eth0 -s0 -n 'udp port 53'Which is guaranteed to show you what's going on. It turns out network manager stashes leases under its own directory. If you use
ps aux | grep dhclientyou can see network manager running dhclient (perhaps multiple instances per interface) and the -lf (lease file) parameter will point you at something like
/var/lib/NetworkManager/dhclient-[guid].leaseMystery solved!
exiv2 -pa myimg.jpgDelete all exif data with this:
exiv2 rm myimg.jpgThere doesn't appear to be a way to just delete the GPS info with exiv2.
sudo apt-get install libimage-exiftool-perlView exif data:
exiftool myimg.jpgDelete just GPS data with this:
exiftool -gps:all= myimg.jpg
sudo apt-get install gnupg-agent scdaemon pcscd pcsc-tools
pcsc_scan gpg --card-status
gpg --import mykey_public_only.ascYou should now be good to go!
gpg --expert --edit-key 123456
trust (set to ultimate)
save
rm -rf ~/.gnupgYou should then be able to import the public key again and get it set up with the new yubikey by running:
gpg --card-status
$ gpg --card-status
gvm install go1.8 gvm use go1.8 gvm pkgenvThis pops $EDITOR which you can use to set your go path to $HOME/go. Check it with:
go env
export PATH=/tmp:$PATH cd /tmp; curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl; chmod 555 kubectlNodes
$ kubectl get nodes $ kubectl get nodes/gke-hello-world-default-pool-9dbb0d2c-5qkl --show-labels $ kubectl label nodes --all mylabel=myvalue $ kubectl label nodes --all mylabel-
$ kubectl get all -n mynamespaceRBAC
kubectl auth can-i --listAll clusterrolebindings:
kubectl get clusterrolebinding -o yamlRole bindings for all namespaces:
kubectl get rolebinding --all-namespaces -o yamlPrivileges of current user:
kubectl create -f - -o yaml << EOF apiVersion: authorization.k8s.io/v1 kind: SelfSubjectRulesReview spec: namespace: system EOF
$ echo 'apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: daemonset-example
spec:
template:
metadata:
labels:
app: daemonset-example
spec:
containers:
- name: daemonset-example
image: ubuntu:trusty
command:
- /bin/sh
args:
- -c
- >-
while [ true ]; do
echo "DaemonSet running on $(hostname)" ;
sleep 10 ;
done
' | kubectl create -f -
$ kubectl delete daemonset daemonset-example
$ kubectl run --rm=true -i --tty ubuntu --image=ubuntu -- /bin/bash # Or with an existing container $ kubectl exec -it shell-demo -- /bin/bash