Consider allowing clients to push encrypted secrets via ssh #18

New Issue

eising · 2025-06-02T16:01:23Z

eising commented

2025-06-02 16:01:23 +00:00

If I want to have something that can be wrapped by podman's secret system, then an ability to create secrets directly on the client would be nice.

This however breaks the current assumptions since those secrets will not be available on the admin interface or in the password database.

I don't want to connect the ssh interface to the admin interface either.

If I want to have something that can be wrapped by podman's secret system, then an ability to create secrets directly on the client would be nice. This however breaks the current assumptions since those secrets will not be available on the admin interface or in the password database. I don't want to connect the ssh interface to the admin interface either.

eising added the

Priority

Low

Kind/Feature

labels 2025-06-02 16:01:23 +00:00

eising added this to the Development and Testing project 2025-06-02 16:01:23 +00:00

eising commented

2025-06-03 05:31:07 +00:00

Some further thoughts:

This should be implemented, and would require the following model changes:

Client Secrets should have an external ID

Client Secrets should have some sort of foreign key to bind them to a secret in the admin interface.

This will allow us to differentiate them on the admin interface.

Clients should be viewed in a tree-view in admin frontend.

  client1
     |
     | - secret1
     | - secret2
  client2
     |
     | - secret1
     | - secret7

Clients should be versioned

Clients should not be deleted. When the ssh key changes, a new client should be created and the old one marked obsolete.

They should still be available in the admin interface. The secrets should be retrievable somehow also.

The ssh key commands should be extended.

If following the podman shelldriver format, the commands should be this:

store
list
lookup
delete

This seems doable too.

Provide example podman driver

In addition to the example client, an example podman driver should be provided.

The example client is not yet checked in, but should.

These could also be fetched via the ssh interface for easy bootstrap.

Scope of work

It's quite a big change, and involves changing quite a bit of the fundamentals.

Some further thoughts: This should be implemented, and would require the following model changes: ### Client Secrets should have an external ID Client Secrets should have some sort of foreign key to bind them to a secret in the admin interface. This will allow us to differentiate them on the admin interface. ### Clients should be viewed in a tree-view in admin frontend. <pre> client1 | | - secret1 | - secret2 client2 | | - secret1 | - secret7 </pre> ### Clients should be versioned Clients should not be deleted. When the ssh key changes, a new client should be created and the old one marked obsolete. They should still be available in the admin interface. The secrets should be retrievable somehow also. ### The ssh key commands should be extended. If following the podman shelldriver format, the commands should be this: - store - list - lookup - delete This seems doable too. ### Provide example podman driver In addition to the example client, an example podman driver should be provided. The example client is not yet checked in, but should. These could also be fetched via the ssh interface for easy bootstrap. ### Scope of work It's quite a big change, and involves changing quite a bit of the fundamentals.

eising added the

Compat/Breaking

label 2025-06-03 05:35:48 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eising/sshecret#18