After setting the SELinux policy below, Keystone has started to work under WSGI. But allowing /etc write access for httpd is not something desirable, I'd guess.

require {
        type httpd_t;
        type etc_t;
        class dir write;
}

#============= httpd_t ==============
allow httpd_t etc_t:dir write;

(In reply to Nerijus from comment #1)
> After setting the SELinux policy below, Keystone has started to work under
> WSGI. But allowing /etc write access for httpd is not something desirable,
> I'd guess.

Not a good idea. 

If you change the label for the path /etc/keystone/fernet-keys to something like keystone_cgi_ra_content_t or keystone_cgi_rw_content_t does this fix your problem?

(In reply to Simon Sekidde from comment #2)
> (In reply to Nerijus from comment #1)
> > After setting the SELinux policy below, Keystone has started to work under
> > WSGI. But allowing /etc write access for httpd is not something desirable,
> > I'd guess.
> 
> Not a good idea. 
> 
> If you change the label for the path /etc/keystone/fernet-keys to something
> like keystone_cgi_ra_content_t or keystone_cgi_rw_content_t does this fix
> your problem?

Simon, your suggestion fixed the problem. I've done the following:
/usr/sbin/semanage fcontext -a -t keystone_cgi_ra_content_t "/etc/keystone/fernet-keys(/.*)?"
/sbin/restorecon -R -v /etc/keystone/fernet-keys

And Keystone has started to issue the tokens. Am I right in thinking that "ra" in keystone_cgi_ra_content_t context means read-only access and "rw" in another of your suggested means read and write?
Now need to ensure that fernet rotation won't change context of key files...

Nejirus, 
Do we know who created "/etc/keystone/fernet-keys"? 
We need to find out which process creating this. Then in SELinux policy we add proper rules to create this dir with correct label.

(In reply to Lukas Vrabec from comment #4)
> Nejirus, 
> Do we know who created "/etc/keystone/fernet-keys"? 
> We need to find out which process creating this. Then in SELinux policy we
> add proper rules to create this dir with correct label.

In usual case it would be 'keystone_manage fernet_setup' command. In my case it's Chef recipe. We run 3 controllers cluster and Chef w/ custom wrapper script is taking care of fernet key distribution across the cluster.

(In reply to Nerijus from comment #5)
> (In reply to Lukas Vrabec from comment #4)
> > Nejirus, 
> > Do we know who created "/etc/keystone/fernet-keys"? 
> > We need to find out which process creating this. Then in SELinux policy we
> > add proper rules to create this dir with correct label.
> 
> In usual case it would be 'keystone_manage fernet_setup' command. In my case
> it's Chef recipe. We run 3 controllers cluster and Chef w/ custom wrapper
> script is taking care of fernet key distribution across the cluster.

OTOH, we use 'keystone_manage fernet_rotate' inside the wrapper script. Just to be on the safe side we put 'restorecon' at the end of it. So, if anything has messed up the file contexts, it would be restored.

Any news on this issue? I've been running into this on OSP 8 as well.

This looks to be a problem in Liberty that was fixed in later OpenStack releases.  The keystone WSGI process should not need wrtie access on the directory where the fernet key(s) reside, but the AVC clearly shows that it is trying to access that directory with write permission.  In the Liberty tree, this happens during a permissions check on the keys directory:

https://github.com/openstack/keystone/blob/stable/liberty/keystone/token/providers/fernet/utils.py#L34-L41

If you look at the Mitaka branch, this method has been changed to only check for write access in certain cases (largely just for use by the keystone_manage CLI, which is unconfined):

https://github.com/openstack/keystone/blob/stable/mitaka/keystone/token/providers/fernet/utils.py#L34-L38

This bug is against a Version which has reached End of Life.
If it's still present in supported release (http://releases.openstack.org), please update Version and reopen.

This was fixed in Mitaka and is in Stable.