Open Stack

Hi Eric,

Thanks for getting back to me.

I'm not looking to develop a real, useful, new service for OpenStack but
develop a dummy service that plugs into OpenStack's authorisation
infrastructure in a way that it looks like an OpenStack service which
integrates with Keystone, like, say the Swift service. See picture
attached, where the swift object represents a resource in the dummy
service.

The dummy service itself is a web-based game of snakes and ladders
written in JavaScript/jQuery which makes Ajax calls to its PEP, written
in PHP. The PHP code interacts with Keystone via the PHP cURL library
and also logs all game actions in a MariaDB database.

The game has been written in a way that it can be exploited by malicious
users who already have access to the system, e.g players can travel up
the snakes or simply ignore the snakes. The idea is that an autonomic
controller is recording the user's actions, analysing them, planning a
response (if necessary) and executing a change. This change could be
inserting a policy line into policy.json or via the congress API. It
could also be removing a role from a user which denies them further
access to the resource in Keystone.

The aim of this research is to produce an effective and efficient means
of mitigating against insider threats directed at computing resources
and information systems. This idea has been previously examined with
LDAP serving as an authentication service and PERMIS serving as an
authorisation service [1]. What is of interest here is porting the setup
to an authorisation infrastructure that is relevant to cloud computing.

I've had a look at congress, I have it running on my game server and it
is registered as a service in Keystone after following [2] (except I
installed the software from CentOS 7 "cloud" repo, "openstack-queens"
[3] but at the moment, calls to the API are returning "Service
Unavailable (HTTP 503)". This may be because there are no datasources
configured. I started to write a driver for the dummy service [4] but as
the game itself does not have a RESTful API, I'm not sure what approach
to take here. I note that this distinction may favour a driver which is
a subclass of PushedDataSourceDriver, rather than
PollingDataSourceDriver. Failing that, I might pursue the Oslo policy 
library route, but again, I'm having difficulty in finding where to 
start. How might you suggest going about making a new, dummy service, 
such as that which I have described?

Best wishes,
Bruno

[1] https://core.ac.uk/download/pdf/30710337.pdf - Chapter 6
[2] https://docs.openstack.org/congress/latest/install/index.html
[3] http://www.mirrorservice.org/sites/mirror.centos.org/7/cloud/x86_64/openstack-queens
[4] https://docs.openstack.org/congress/latest/user/cloudservices.html#drivers


From: Eric K <ekcs.openstack at gmail.com>
Sent: 16 August 2018 22:17
To: openstack at lists.openstack.org
Cc: B.M.Canning
Subject: Re: [Openstack] [OpenStack][Keystone][new_service]
  

Hi Bruno!

What is the new service you're looking to develop?

I think the answer depends on your needs. Most openstack projects use
the oslo policy library as a PDP to protect API access [1]. On the
other hand, if you want dynamic rules and very fine-grained access
control, you may also consider Openstack Congress [2] which offers a
general and flexible rule framework.

Either way, here is how it typically works in an openstack service:
Policy rules are written and stored in the chosen policy framework.
For oslo policy, this is typically the json file containing policy
rules. In Congress, the policy store is managed by Congress service
and accessed via Congress API.
When an API is accessed, the service serving the API acts as the PEP.
It consults the PDP to see whether something is allowed, and enforces
that decision. For oslo policy, this is a library call [3]. For
Congress, this is an API call to Congress service to query the result
of rule evaluation [4][5].

For oslo policy, the main PAP is the json file containing the policy
rules. For congress, the policies and rules are managed through the
Congress API/GUI/client.

Hope that helps. Happy to talk further!

Eric
OpenStack Congress contributor

[1]  https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#
[2] https://docs.openstack.org/congress/latest/user/policy.html#
[3]  https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#generic-checks
[4]  https://docs.openstack.org/congress/latest/user/api.html#policy-table-rows-v1-policies-policy-id-tables-table-id
[5]  https://github.com/openstack/python-congressclient/blob/master/congressclient/v1/client.py#L113

On Wed, Aug 15, 2018 at 8:29 AM, B.M.Canning <bmc20 at kent.ac.uk> wrote:
> Dear OpenStackers,
>
> Hello, I'm new to the list.
>
> I would like to know what support is available for creating a new
> OpenStack service that contains role-based access control components,
> such as a Policy Decision Point (PDP), inside the new service.
>
> I have come across oslo.policy in my research, is this what other OpenStack
> components use for their PEP, PDP, PAP and PIP? If so, what resources are
> available to help developers use this framework in their projects?
>
> Background:
> As part of my MSc degree in computer science, I am conducting a research
> project into the application of self-adaptation in authorisation
> infrastructures as a means of mitigation against insider threats towards
> cloud computing infrastructures. I'm using Keystone as a role-based
> access control system to protect access to a web-based game, and actions
> that a player can perform in the game, which represents computing
> resources, here snakes and ladders. Cheating in the game represents the
> malicious behaviour of an insider threat, to which the authorisation
> infrastructure responds by reducing/removing the user's privileges. The
> intention is to have the game represent an OpenStack service, like
> Swift. I am currently using the Queens release of Keystone and v3 of the
> API for both service-level and infrastructure-level policy decisions.
>
> Best wishes,
> Bruno Canning
>
> School of Computing, University of Kent
> _______________________________________________
> Mailing list:  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: os-keystone-swift-auth-arch.png
Type: image/png
Size: 128006 bytes
Desc: os-keystone-swift-auth-arch.png
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20180817/28fbb1a1/attachment.png>