Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Dolph Mathews]

+1 this is a totally logical move, especially given that the current
implementation back to the /v3/credentials API anyway.

On Friday, February 5, 2016, Morgan Fainberg 
wrote:

> Looking over the state [and relatively untested nature] of the Keystone
> EC2 API and S3Token APIs, I want to propose deprecating these mechanisms of
> auth within Keystone at this time.
>
> These systems have been historically poorly tested and supported and have
> remained broken / incompatible for long periods at a time. With the move
> that the EC2-API team is taking the code from nova out-of-tree, I would
> like to propose that the auth mechanisms are also moved out of tree and
> into the purview of the team focused on providing a solid EC2 compatibility
> layer for OpenStack.
>
> This will allow the EC2-API team to better ensure the long term viability
> and compatibility of the required auth systems and can free this all from
> the requirement to propose code to keystone to handle forward momentum as
> required to support future/new signature versions and movement within the
> libraries that rely on clear AWS compatibility.
>
> This should ideally be moved to something standalone that can handle the
> translation of EC2 or S3Token Auth to native Keystone api calls.
>
> Thanks for reading,
> --Morgan
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Tim Bell]

>
> Is it certain that there is no need for the functions with the new EC2-API 
> functions ?
>
> The S3 functions are somewhat separated from the EC2 API. How does SWIFT 
> implement the S3 compatibility layer ?
>
> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make 
> sure we’re not using it somewhere else.
>

This would be just a deprecation warning. Removal would be determined at a 
later time with sufficient lead time.

Do you know how S3 with SWIFT works ? Would they need to do something like 
EC2-API ?

Tim



smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Morgan Fainberg]

On Feb 5, 2016 09:43, "Tim Bell"  wrote:
>
>
> Is it certain that there is no need for the functions with the new
EC2-API functions ?
>
> The S3 functions are somewhat separated from the EC2 API. How does SWIFT
implement the S3 compatibility layer ?
>
> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
make sure we’re not using it somewhere else.
>

This would be just a deprecation warning. Removal would be determined at a
later time with sufficient lead time.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Tim Bell]

Is it certain that there is no need for the functions with the new EC2-API 
functions ?

The S3 functions are somewhat separated from the EC2 API. How does SWIFT 
implement the S3 compatibility layer ?

Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make sure 
we’re not using it somewhere else.

Tim

From:  Dolph Mathews
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
Date:  Friday 5 February 2016 at 17:07
To:  "OpenStack Development Mailing List (not for usage questions)"
Subject:  Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token 
to Externally supported

+1 this is a totally logical move, especially given that the current 
implementation back to the /v3/credentials API anyway.

On Friday, February 5, 2016, Morgan Fainberg <morgan.fainb...@gmail.com> wrote:
Looking over the state [and relatively untested nature] of the Keystone EC2 API 
and S3Token APIs, I want to propose deprecating these mechanisms of auth within 
Keystone at this time.

These systems have been historically poorly tested and supported and have 
remained broken / incompatible for long periods at a time. With the move that 
the EC2-API team is taking the code from nova out-of-tree, I would like to 
propose that the auth mechanisms are also moved out of tree and into the 
purview of the team focused on providing a solid EC2 compatibility layer for 
OpenStack.

This will allow the EC2-API team to better ensure the long term viability and 
compatibility of the required auth systems and can free this all from the 
requirement to propose code to keystone to handle forward momentum as required 
to support future/new signature versions and movement within the libraries that 
rely on clear AWS compatibility.

This should ideally be moved to something standalone that can handle the 
translation of EC2 or S3Token Auth to native Keystone api calls.

Thanks for reading,
--Morgan



smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Andrey Pavlov]

swift3(s3) works like ec2-api.

1. swift3/ec2-api recieves AWS request
2. it parses signature and access_key (and other headers)
3. it sends these values (and token that calculated from request) to keystone
4. keystone gets secret_key from DB, then calculates signature by
recieved access_key and token
5. keystone compares recived signature and claculated signature and
then return 'error' or auth_token
6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
or continues execution
7. in case of continue swift3/ec2-api uses recieved auth_token for
calls other services: nova, cinder, neutron, swift...

So I don't understand how implement this functionality outside of keystone...

On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>
>>
>> Is it certain that there is no need for the functions with the new EC2-API
>> functions ?
>>
>> The S3 functions are somewhat separated from the EC2 API. How does SWIFT
>> implement the S3 compatibility layer ?
>>
>> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make
>> sure we’re not using it somewhere else.
>>
>
> This would be just a deprecation warning. Removal would be determined at a
> later time with sufficient lead time.
>
> Do you know how S3 with SWIFT works ? Would they need to do something like
> EC2-API ?
>
> Tim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Dolph Mathews]

On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:

> swift3(s3) works like ec2-api.
>
> 1. swift3/ec2-api recieves AWS request
> 2. it parses signature and access_key (and other headers)
> 3. it sends these values (and token that calculated from request) to
> keystone
> 4. keystone gets secret_key from DB, then calculates signature by
> recieved access_key and token
> 5. keystone compares recived signature and claculated signature and
> then return 'error' or auth_token
> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
> or continues execution
> 7. in case of continue swift3/ec2-api uses recieved auth_token for
> calls other services: nova, cinder, neutron, swift...
>
> So I don't understand how implement this functionality outside of
> keystone...
>

EC2 support is implemented in middleware on top of keystone, and that
middleware happens to live in the openstack/keystone repository. This
change is just proposing to move that middleware code into a dedicated new
repository and change the community support & maintenance model - it would
not affect how the code actually operates. The only affect on operators is
that it would require an extra step to deploy it. End users would not be
affected.

https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27

https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31


>
> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
> >
> >>
> >> Is it certain that there is no need for the functions with the new
> EC2-API
> >> functions ?
> >>
> >> The S3 functions are somewhat separated from the EC2 API. How does SWIFT
> >> implement the S3 compatibility layer ?
> >>
> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
> make
> >> sure we’re not using it somewhere else.
> >>
> >
> > This would be just a deprecation warning. Removal would be determined at
> a
> > later time with sufficient lead time.
> >
> > Do you know how S3 with SWIFT works ? Would they need to do something
> like
> > EC2-API ?
> >
> > Tim
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Andrey Pavlov]

Can it be implemented as keystone plugin?
Is it possible to 'get' AUTH_TOKEN outside of keystone?
Will this code use keystone DB or it should create own?

So we will need one 'auth' module for swift3/ec2-api.
Sounds good but we need to understand some details before implementation.

On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  wrote:
>
> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:
>>
>> swift3(s3) works like ec2-api.
>>
>> 1. swift3/ec2-api recieves AWS request
>> 2. it parses signature and access_key (and other headers)
>> 3. it sends these values (and token that calculated from request) to
>> keystone
>> 4. keystone gets secret_key from DB, then calculates signature by
>> recieved access_key and token
>> 5. keystone compares recived signature and claculated signature and
>> then return 'error' or auth_token
>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>> or continues execution
>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>> calls other services: nova, cinder, neutron, swift...
>>
>> So I don't understand how implement this functionality outside of
>> keystone...
>
>
> EC2 support is implemented in middleware on top of keystone, and that
> middleware happens to live in the openstack/keystone repository. This change
> is just proposing to move that middleware code into a dedicated new
> repository and change the community support & maintenance model - it would
> not affect how the code actually operates. The only affect on operators is
> that it would require an extra step to deploy it. End users would not be
> affected.
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>
>>
>>
>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>> >
>> >>
>> >> Is it certain that there is no need for the functions with the new
>> >> EC2-API
>> >> functions ?
>> >>
>> >> The S3 functions are somewhat separated from the EC2 API. How does
>> >> SWIFT
>> >> implement the S3 compatibility layer ?
>> >>
>> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
>> >> make
>> >> sure we’re not using it somewhere else.
>> >>
>> >
>> > This would be just a deprecation warning. Removal would be determined at
>> > a
>> > later time with sufficient lead time.
>> >
>> > Do you know how S3 with SWIFT works ? Would they need to do something
>> > like
>> > EC2-API ?
>> >
>> > Tim
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Kind regards,
>> Andrey Pavlov.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,
Andrey Pavlov.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Brant Knudson]

On Fri, Feb 5, 2016 at 1:03 PM, Dolph Mathews 
wrote:

>
> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov 
> wrote:
>
>> swift3(s3) works like ec2-api.
>>
>> 1. swift3/ec2-api recieves AWS request
>> 2. it parses signature and access_key (and other headers)
>> 3. it sends these values (and token that calculated from request) to
>> keystone
>> 4. keystone gets secret_key from DB, then calculates signature by
>> recieved access_key and token
>> 5. keystone compares recived signature and claculated signature and
>> then return 'error' or auth_token
>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>> or continues execution
>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>> calls other services: nova, cinder, neutron, swift...
>>
>> So I don't understand how implement this functionality outside of
>> keystone...
>>
>
> EC2 support is implemented in middleware on top of keystone, and that
> middleware happens to live in the openstack/keystone repository. This
> change is just proposing to move that middleware code into a dedicated new
> repository and change the community support & maintenance model - it would
> not affect how the code actually operates. The only affect on operators is
> that it would require an extra step to deploy it. End users would not be
> affected.
>
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>
>

One of the things that prompted this discussion is a proposal to make EC2
and S3 required, and not removable by editing the paste config:
https://review.openstack.org/#/c/274973/

Some of us were taking advantage of this ability, but others think that all
APIs should be supported.

- Brant
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev