Before adding security tools, identify what could go wrong with the service you are building. A leaked credential, an overly broad permission and a lost database need different protections.

A threat model is a practical account of what you are protecting, who or what can reach it and how it could be harmed. Start with one application: list its data, accounts and entry points. Choose access restrictions to prevent mistakes, useful records to notice them and a recovery procedure for the failures you cannot prevent.

Try it in a lab

Describe a disposable service and its sensitive assets. List entry points, privileged operations and likely mistakes. For each one, identify an access control, an observable signal and a recovery action.

Check your understanding

Explain how a credential is revoked, how a configuration change is attributed and how lost data is recovered. Test a harmless denied-access case in the lab.

Before you start

Do not run intrusive scans or attack simulations against systems you do not own or have permission to test. Use synthetic data and scoped credentials.

Read the official guide

Use the project documentation for version-specific commands and prerequisites. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.

This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.

Sources & further reading

  1. Primary learning documentation

Spotted something that needs another look?

Help improve this page →