By leveraging sops (https://github.com/mozilla/sops), it is possible to save secrets to a third-party key store instead of storing them locally in-memory.

this can be part of aegis.z2h.dev too.

if these kinds of contents will increase, it might be time to switch to jeykll or some other static content generator too.

By leveraging sops (https://github.com/mozilla/sops), it is possible to save secrets to a third-party key store instead of storing them locally in-memory.

By leveraging sops (https://github.com/mozilla/sops), it is possible to save secrets to a third-party key store instead of storing them locally in-memory.

Do some minimally responsive adjustments.

Here’s the reasoning:

We already secure sentinel-to-safe connectivity using mTLS. So, as long as no one can impersonate sentinel, sentinel can happily authenticate and authorize with safe.

We just need to secure access to sentinel with a role similar to this:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: aegis-system
  name: aegis-admin
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

Then, only the users bound to this role (and also cluster admins) can kubectl exec on sentinel.

Since sentinel does not have any external-facing API, that will be the only way to generate secrets on the system.

Then, assuming SPIRE is happy as a clam, creating a secret will be as simple as something like this:

kubectl exec -it aegis-sentinel-aabbcc -- /bin/aegis secret \
--id workloadSvid \
--value "secretValue"

Things to do:

1. Use Ansible to talk to safe and fetch the admin token and also the private key
2. Create some secrets and ensure that the workload sees those secrets.
3. Manually delete the safe pod to emulate a crash
4. Ensure that the persistent volume has state info when the new pod initializes.
5. restore the state using ansible (assuming you have private key stored somewhere from previous steps)
6. make sure that the workload sees secrets.

or not… since all of the aegis servers are not externally consumed; they don’t share anything between each other.

could be a part of the aegis.z2h.dev static website to keep things consistent.

We can start with a Go SDK and officially support it.
Better to support one SDK well than supporting 10 SDKs poorly.

We don’t need CI here since we’ll use kubectl as our de facto way to interact with Aegis.

Just a script on the project root that reads an AEGIS_SENTINEL_POD_NAME environment variable and executes whatever script necessary on sentinel will be sufficient.

like cluster name, cluster trust domain etc.
could be a simple go command line application.

Update the main README, and also READMEs of the child projects.

Make sure you add any missing license information for external dependencies that you leverage.

safe needs an API endpoint (secured with mTLS leveraging SPIRE SVIDs as certs) to deliver the AdminToken to the (human) operator.

Acceptance Criteria:

1. safe shall have an AEGIS_ADMIN_SVIDS as an environment variable. Only these svids shall be able to use the token fetch API. (this can be useful to automate the process: CI can create a pod with an allowed SVID, call the admin API, fetch the token, store the token, and then create secrets for pods using that token).
2. from sentinel call that API to fetch the token.
3. from sentinel use the token to generate secrets for the demo workload.
4. ensure that demo workload fetches the secrets.

Note that 4. requires to update sidecar to query safe for secrets over mTLS: Better to start there.

Right now, safe.z2h.dev is pretty blank. At least add some summary and some minimal design to it.

I’m not sure if this is really necessary because it’s often better to keep secrets sources closer to secret consumers (i.e. everything within the same cluster); but there might be use cases that require this, so it’s worth at least to think about that and come up with a stable-enough use case.

https://github.com/GoogleContainerTools/distroless

By leveraging sops (https://github.com/mozilla/sops), it is possible to save secrets to a third-party key store instead of storing them locally in-memory.

After introducing SPIRE, we retired notary, that also resulted in AdminToken not being delivered to safe anymore.

But the thing is, safe can very well use whatever random token generation logic notary has to create the same toke for itself once the pod starts.

Make sure that things, at least work cross-cloud.

Aegis stores everything in memory by design because it is the safest way to deal with sensitive data; however, that also means that when safe is evicted or crashed and reboots, all the stored secrets and admin token is gone.

Acceptance Criteria:

1. safe shall have an API endpoint that only allowed admin svids can call. This API will return a private key and a public key pair.
2. safe shall create Kubernetes secrets that only safe can reach and store the private and public keys.
3. safe will encrypt its state to a persistent volume using the public key.
4. upon restart safe will restore its state into memory using the private key.

Consider using age as an encryption tool https://github.com/FiloSottile/age

Right now SPIRE uses a directory mount because there is some configuration problem in the workloads that prevent the workloads from mounting the socket volume.

And adaptation from the following file can likely fix it:
https://github.com/spiffe/spiffe-csi/blob/main/example/config/workload.yaml

Using CSI Driver is more secure and recommended, so better to give a shot at it.