Fedora Server Role D-BUS API Design Discussion

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/25/2014 11:00 AM, Thomas Woerner wrote:
> Hello,
> 
> On 03/20/2014 02:00 PM, Stephen Gallagher wrote:

>>>>> == Open questions ==
>>>>> 
>>>>> 1) How do we handle configuring the Firewall? I think we
>>>>> want to have a Firewall object 
>>>>> (/org/fedoraproject/server/RoleFirewallManager) available
>>>>> to query the firewall as a whole, but we may also want to
>>>>> be able to view and apply firewall rules from the Role
>>>>> objects directly. (Note: I'm not suggesting we need a
>>>>> complete firewall solution here. This should be a wrapper
>>>>> that deals only with the Roles). Firewalld already provides
>>>>> a more comprehensive firewall interface for the general
>>>>> case.
>>>> 
>>>> Should we try and rope in the firewalld maintainer(s) here?
>>>> They may have some ideas on how to do this so it causes the
>>>> least amount of pain.
> 
> Yes, good idea. I'm CCing Thomas Woerner and will politely ask him
> to review this thread.[1]
> 
> 
>> I have been on vacation and are in the office since today again.
> 
>> What exactly do you want to be able to configure? Do you think
>> of something like firewall zones or more fine grained
>> configuration options like for example ports or direct rules?
> 


I'm not going to attempt to specify an implementation right now. I'd
rather state the problem space as I see it and have you recommend an
approach instead.

So to restate the problem:
One of the primary goals of the Fedora Server product is to be able to
package up some common IT infrastructure components and provide an
easy way to deploy them on a physical or virtual machine[1]. Some
representative examples of this are a Domain Controller (FreeIPA) and
a Database Server (PostgreSQL).

We are working on building a D-BUS API and listener on Fedora Server
systems whose duty it is to install the requisite packages and deploy
a fully-functional Server Role onto the system.

Part of being a fully-functional part of infrastructure is having
those services be accessible by the appropriate clients. The Role
itself will "know" what ports it needs open, and this will be possible
to query through the D-BUS API in some manner TBD. We need a way in
the D-BUS API for an administrator to grant access to those requested
ports on some or all network interfaces attached to the machine. We
also want this interface to have an association with the Role object
in the system, so that a client such as Cockpit can easily query a
Role for "What ports do you need and on which interfaces can that port
be reached?" Furthermore, we want there to be a mechanism to apply a
set of very simple changes.

For a real-world example:
I have decided to stand up a database server. While I'm setting it up,
managing permissions and filling it with data, I want to keep this
private, so I only want access to be allowed on the 'lo' interface. I
want this to be done atomically as part of the initial deployment, so
I don't have any race-conditions to worry about where my database
might have been visible externally.

Once that is prepared, my tests are all complete and I know it's safe
to expose the database to the external interfaces. I have two external
ethernet interfaces. One is to the public network and the other is a
private internal connection (a storage network or management plane,
etc.) At this time, I want to update the firewall so that only 'lo'
and the public network have access to the set of ports required by my
database server.

Also, in cases where a Role might require more than one port (such as
the Domain Controller) I might also want to only allow a subset of the
Role's ports access on a particular interface.

Finally, I want this ability to allow access to some or all required
ports on some or all available interfaces to be offered by the
Deployment phase as well (in the same atomic manner as my example above).

I hope that describes the problem space sufficiently well. My
colleagues in the Server SIG can correct me if I got any of the
details wrong.


[1] I'm intentionally leaving containers out of the discussion for the
moment.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMxvRYACgkQeiVVYja6o6MKcQCghA/naqrGVinqvXQq4ECwvYuf
fQsAnjQoFQpJo0dHWQzs/2//aESw5sSu
=7jSs
-----END PGP SIGNATURE-----