Re: [openstack-dev] Regarding cache-based cross-VM side channel attacks in OpenStack
Hi Darshan, I believe you are referring to the recent Foreshadow / l1tf vulnerability? If that's the case OpenStack compute workloads are protected with all relevant to the specific hypervisor type mechanisms. AFAIK OpenStack at this moment supports KVM-Qemu, Xen, vSphere/ESXI and Hyper-V hypervisors. All of the above hypervisors offer side channel protection mechanisms implementations. You can also consult OpenStack Security Guide, compute sections seems to be most relevant to the question you raised, https://docs.openstack.org/security-guide/compute.html HTH, On Fri, Aug 24, 2018 at 7:35 AM Darshan Tank wrote: > Dear Sir, > > I would like to know, whether cache-based cross-VM side channel attacks > are possible in OpenStack VM or not ? > > If the answer of above question is no, then what are the mechanisms > employed in OpenStack to prevent or to mitigate such types of security > threats? > > I'm looking forward to hearing from you. > > Thanks in advance for your support. > > With Warm Regards, > *Darshan Tank * > > [image: Please consider the environment before printing] > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [freezer] PTG planning Etherpad
Hello Saad, I think you missed link to the [1] etherpad. On Mon, Feb 12, 2018 at 3:05 PM, Saad Zaher <eng.sza...@gmail.com> wrote: > Hello everyone, > > Please, if anyone is going to attend the next PTG in dublin check ehterpad > [1] for discussion agenda. > > Feel free to add or comment on topics you want to discuss in this PTG. > > Please make sure to add your irc or name to participants section. > > > Best Regards, > Saad! > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Upcoming Deadlines
Thanks Lance for a comprehensive summary. However I'm bit puzzled with application credentials spec, specifically with the sentence 'This model, while convenient for keystone, increases the risk of account compromise by requiring the distribution of unencrypted passwords.' My personal preference for securing OS cloud credentials is to leverage X.509/PKI rather than username and password. X.509 authN plugin is available since some time ago [4] and I'd really appreciate if Keystone team could explain how app credentials will interact with existing (e.g. x.509) authN plugin in federated scenario. How role assignment derived from federation mapping (and x.509 certificate) is going to interact with application credentials? This is important for me since I received a lot of complains about clear text passwords and typically my recommendation is to mitigate it with said x.509 approach. [4] https://review.openstack.org/#/c/283905/16 [5] https://docs.openstack.org/keystone/pike/advanced-topics/federation/mapping_combinations.html On Mon, Dec 11, 2017 at 11:37 PM, Lance Bragstad <lbrags...@gmail.com> wrote: > Sending out a gentle reminder that feature proposal freeze will be next > week. It looks like all possible features are in flight based on the > current state of the specs repository. The only exception is the unified > limit specification, which was rebased and passing today [0]. > > Thanks! > > [0] https://review.openstack.org/#/c/455709/ > > On 11/20/2017 11:25 AM, Lance Bragstad wrote: > > Sending out a reminder that we have a couple deadlines approaching. > > > > First, *specification* *freeze* is *two weeks away*. Here is a short > > list of things we've committed to but need the specification to merge: > > > > - Unified Limits API [0] > > - Application Credentials [1] > > - System Scope [2] > > - Scope Types [3] > > > > These reviews should take priority. > > > > Second, *feature* *proposal* *freeze* is *four weeks away*. Remember > > that this deadline falls earlier than last release due to the holiday > > season. So far, only application credentials and unified limits are > > missing proposed implementations. Again, these are just proposals. > > Feature freeze is January 26th. > > > > If you have spare cycles and want to tag-team one of these efforts > > with an existing owner, please don't hesitate to reach out. Let me > > know if there is anything I've missed. Thanks! > > > > > > [0] https://review.openstack.org/#/c/455709/ > > [1] https://review.openstack.org/#/c/512505/ > > [2] https://review.openstack.org/#/c/464763/ > > [3] https://review.openstack.org/#/c/500207/ > > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] multiple federated keystones with single Identity Provider
Hi Pavlo, I think that there are viable alternatives to your specific use case having single external idp for federated auth. Depending on your IT environment architecture and preferences you have the following possibilities, both of them are providing very smooth user experience: - in AD centric environments connect each of Keystone services to AD and leverage Kerberos for SSO. You can consume REMOTE_USER and other variables from AD directly via mod_auth_gssapi and mod_lookup_identity. Advantage of this approach is that you can leverage AD native SSO mechanism based on SPNEGO. So you are not any longer forcing users to perform SAML or OIDC referrals etc. - in both AD or non AD centric environments you can leverage 'Tokenless Auth' plugin, which basically can also be used with Keystone to issue tokens (e.g. Fernet) and perform token scoping based on X.509 certificate properties. You can also configure specific X.509 certificate attributes e.g. SAN or subjectDirectoryAttributes to control access for specific region or Keystone instance. On Fri, Dec 8, 2017 at 1:25 AM, Boris Bobrov <bre...@cynicmansion.ru> wrote: > Hi, > > > On 12/07/2017 12:27 PM, Colleen Murphy wrote: > >> On Thu, Dec 7, 2017 at 5:37 PM, Pavlo Shchelokovskyy > >> <pshchelokovs...@mirantis.com> wrote: > >>> Hi all, > >>> > >>> We have a following use case - several independent keystones (say KeyA > and > >>> KeyB), using fernet tokens and synchronized fernet keys, and single > external > >>> IdP for federated auth. > >>> > >>> Is it generally possible to configure both KeyA and KeyB such that > scoped > >>> token issued by KeyA for a federated user is valid on KeyB? > >>> > >>> Currently we have the next problem - although domains/projects where > >>> keystone's mapping engine assigns federated users are equal by name > between > >>> KeyA and KeyB, the UUIDs of projects/domains in KeyA and KeyB are > >>> different, which seems to invalidate the scoped token issued by KeyA > when > >>> trying to use it for KeyB. And it is not possible to create > projects/domains > >>> with specific UUIDs via keystone API (which would probably solve this > >>> problem for non-autoprovisioned projects). > >>> > >>> Is such usage scenario supported? Or one should always use the unscoped > >>> token first to list projects/domains available on a specific keystone > >>> instance and then get a scoped token for usage o this instance only? > >> No, it is not currently possible to use the same token on projects in > >> different keystones, for the reasons you gave. You might be interested > >> in following https://review.openstack.org/#/c/323499/ if you're not > >> already aware of it, which has the goal of solving that problem. > >> > >> It's also been brought up before: > >> > >> https://review.openstack.org/#/c/403866/ > >> http://lists.openstack.org/pipermail/openstack-dev/2016- > December/108466.html > >> > >> And we talked about it a lot at the last Forum (sorry my brief summary > >> does not really do the discussion justice): > >> > >> http://www.gazlene.net/sydney-summit.html#keystone-operator- > and-user-feedback > > I had a snippet about it in my recap under the "Other Feedback" section > > [0]. The TL;DR in my opinion is that we originally thought we could > > solve the problem with federation 100%, and if we couldn't we wanted to > > try and improve the parts of federation that would make that possible. > > > > The interesting bit we came up with during the feedback session in > > Sydney is what happens if a user no longer has a role on a project. For > > example; > > > > - A user has a role on Project A and in the us-east region and the > > us-west region, each region has it's own keystone deployment, but let's > > assume the ID for Project A are the same in each region > > - A user authenticates for a token scoped to Project A and starts > > creating instances in both regions > > - The user has their role from Project A removed in us-east, but not in > > us-west > > - The user isn't able to do anything within us-east since they no longer > > have a role assignment on Project A in that region, but they can still > > take the invalid token from the us-east region and effectively use it in > > the us-west region > > > > Without replicating revocation events, or syncing the assignment table, > > this will lead to security concerns. > > There is also cache invalidation iss
Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update
org/irclogs/%23openstack-lbaas/%23opensta > > >>> ck > > >>> -lbaas.2017-10-06.log.html#t2017-10-06T02:50:10 > > >>> [3] https://review.openstack.org/#/c/509389/ > > >>> > > >>> Dai > > >>> > > >>> > > >> > > ___ > > >> ___ > > >>> 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 > > > > > > ___ > > ___ > > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [hyper-v] Hyper-V Support Will be Removed Forever ?
In regards to these benchmarks honestly I don't think that the measurement results are objective enough. According to my past experiences with Hyper-v Microsoft's hypervisor heavily uses block layer caching also for guest read/write operations. AFAIK this is very different to Linux+KVM or VMware where there is no caching for vm guests. On Fri, Nov 24, 2017 at 4:46 PM, Alessandro Pilotti < apilo...@cloudbasesolutions.com> wrote: > Hyper-V support in OpenStack is alive and well, see for example this blog > series comparing KVM and Hyper-V: [1]. > > The fact that SUSE / HPE might or might not support it, is just a matter > of commercial choices unrelated to the upstream projects (which is what > matters in this ML). Other vendors (e.g. Red Hat, Mirantis, Canonical) have > partnership with us (Cloudbase) for Hyper-V commercial support. > > Cheers, > > Alessandro > > [1] https://cloudbase.it/openstack-newton-benchmarking-part-5/ > > On 24 Nov 2017, at 17:19, Vahric MUHTARYAN <vah...@doruk.net.tr> wrote: > > Hello, > > > > We are using HPE Helion Openstack . For a long time they are always > removing hyper-v support from their distro. We started to discuss with > SUSE and i believe everybody know HPE HOS and SUSE Openstack are migratated > and it will become single product and we learn from SUSE they are also stop > supporting Hyper-V. > > > > I know cloudbase.it working hard for port too much thing but ı would like > to learn really Hyper-V hypervisor support will be removed from Openstack > forever ? > > > > Regards > > VM > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [security] [api] Script injection issue
Thanks TommyLike for this bug report. Sounds like Stored XSS [1]. Could you please share more details, e.g. branch / release, APIs tested etc.? [1] https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting On Fri, Nov 17, 2017 at 12:36 PM, Davanum Srinivas <dava...@gmail.com> wrote: > Adding [api] to make sure the API (SIG?) sees this too > > On Fri, Nov 17, 2017 at 3:22 AM, TommyLike Hu <tommylik...@gmail.com> > wrote: > > Hey all, > > Recently when we integrating and testing OpenStack services. We > found > > there is a potential script injection issue that some of our services > accept > > the input with special character [1] [2], for instance we can create an > > instance or a volume with the name of 'script inside'. > One > > of the possible solutions is add HTML encode/decode support in Horizon, > but > > it's not guaranteed every OpenStack user is using Horizon. So should we > > apply more strict restriction on user's input? > > Also, I found Google Cloud have a strict and explicit restrction in > > their instance insert API document [3]. > > > > [1]: Nova: > > https://github.com/openstack/nova/blob/master/nova/api/ > validation/parameter_types.py#L148 > > [2]: Cinder: > > https://github.com/openstack/cinder/blob/master/cinder/api/ > openstack/wsgi.py#L1253 > > [3]: Google Cloud: > > https://cloud.google.com/compute/docs/reference/latest/instances/insert > > > > Thanks > > TommyLike.Hu > > > > > > > > > __ > > 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 > > > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > ______ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [policy] AWS IAM session
Hi Devdatta, excellent post on IAM models. Thank you! On Wed, Oct 4, 2017 at 10:59 PM, Devdatta Kulkarni < kulkarni.devda...@gmail.com> wrote: > +1 > > I spent some time recently studying IAM models of AWS and GCP. > Based on this I had created following post comparing and summarizing the > two models at high-level: > > http://devcentric.io/2017/07/13/comparing-iam-models-of-aws-and-gcp/ > > Thought of sharing it here as it may help with big-picture comparison of > the two models. > > Best regards, > Devdatta > > > On Wed, Oct 4, 2017 at 11:12 AM, Kristi Nikolla <kri...@nikolla.me> wrote: > >> +1 >> >> -- >> Kristi Nikolla >> Software Engineer @ massopen.cloud >> kri...@nikolla.me >> >> On Wed, Oct 4, 2017, at 10:08 AM, Zane Bitter wrote: >> > On 03/10/17 16:08, Lance Bragstad wrote: >> > > Hey all, >> > > >> > > It was mentioned in today's keystone meeting [0] that it would be >> useful >> > > to go through AWS IAM (or even GKE) as a group. With all the recent >> > > policy discussions and work, it seems useful to get our eyes on >> another >> > > system. The idea would be to spend time using a video >> conference/screen >> > > share to go through and play with policy together. The end result >> should >> > > keep us focused on the implementations we're working on today, but >> also >> > > provide clarity for the long-term vision of OpenStack's RBAC system. >> > > >> > > Are you interested in attending? If so, please respond to the thread. >> > > Once we have some interest, we can gauge when to hold the meeting, >> which >> > > tools we can use, and setting up a test IAM account. >> > >> > +1, I'd like to attend this. >> > >> > Also I highly recommend >> > http://start.jcolemorrison.com/aws-iam-policies-in-a-nutshell/ over the >> > actual AWS docs as a compact reference. >> > >> > - ZB >> > >> > > Thanks, >> > > >> > > Lance >> > > >> > > [0] >> > > http://eavesdrop.openstack.org/meetings/keystone/2017/keysto >> ne.2017-10-03-18.00.log.html#l-119 >> > > >> > > >> > > >> > > >> > > >> __ >> > > OpenStack Development Mailing List (not for usage questions) >> > > Unsubscribe: openstack-dev-requ...@lists.op >> enstack.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 >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Security of Meta-Data
Referring to the original question 'Note that CloudInit allows passing user and ssh service public/private keys via MetaData service (or ConfigDrive). One assumes it must be secure, but I have not found a security model or documentation.' The metadata service is as secure as underlaying infrastructure supporting it. Now take into account that Nova communicates with Neutron via API, you typically enter your SSH public (not private) key with API etc. Clearly API endpoint security and all API supporting infra are key players here. My recommendation it to ensure that your APIs and supporting infra are secured according to your specific requirements. You may want to develop your own threat model, analyse risks relevant to your infrastructure, apply appropriate controls. You may find security guide useful, https://docs.openstack.org/security-guide/ On Wed, Oct 4, 2017 at 8:12 AM, Gary Kotton <gkot...@vmware.com> wrote: > Hi, > You can configure the metadata service to be secure. You just need to make > sure that nova is configured correctly. FYI - > https://github.com/openstack/neutron/blob/master/neutron/ > conf/agent/metadata/config.py#L68 > Thanks > Gary > > On 10/4/17, 7:01 AM, "Joshua Harlow" <harlo...@fastmail.com> wrote: > > I would treat the metadata service as not secure. > > From amazon docs (equivalent can be said about openstack): > > ''' > Important > > Although you can only access instance metadata and user data from > within > the instance itself, the data is not protected by cryptographic > methods. > Anyone who can access the instance can view its metadata. Therefore, > you > should take suitable precautions to protect sensitive data (such as > long-lived encryption keys). You should not store sensitive data, such > as passwords, as user data. > ''' > > https://urldefense.proofpoint.com/v2/url?u=http-3A__docs. > aws.amazon.com_AWSEC2_latest_UserGuide_ec2-2Dinstance- > 2Dmetadata.html=DwIGaQ=uilaK90D4TOVoH58JNXRgQ= > PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw= > 6hYo6Fh9CLmjqptic1Jk22ZN3jgrnjOSs2p_8Opv7oo=XOsLXFFKlrL9E_ > B_lgNqvvqvTOKic_rIAJpQdVTMryg= > > So private keys would be a no-no, public keys would be ok (since they > are public anyway). > > Giuseppe de Candia wrote: > > Hi Folks, > > > > > > Are there any documented conventions regarding the security model for > > MetaData? > > > > > > Note that CloudInit allows passing user and ssh service > public/private > > keys via MetaData service (or ConfigDrive). One assumes it must be > > secure, but I have not found a security model or documentation. > > > > > > My understanding of the Neutron reference implementation is that > > MetaData requests are HTTP (not HTTPS) and go from the VM to the > > MetaData proxy on the Network Node (after which they are proxied to > Nova > > meta-data API server). The path from VM to Network Node using HTTP > > cannot guarantee confidentiality and is also susceptible to > > Man-in-the-Middle attacks. > > > > Some Neutron drivers proxy Metadata requests locally from the node > > hosting the VM that makes the query. I have mostly seen this > > presented/motivated as a way of removing dependency on the Network > node, > > but it should also increase security. Yet, I have not seen explicit > > discussions of the security model, nor any attempt to set a standard > for > > security of the meta-data. > > > > Finally, there do not seem to be granular controls over what > meta-data > > is presented over ConfigDrive (when enabled) vs. meta-data REST API. > As > > an example, Nova vendor data is presented over both, if both are > > enabled; config drive is presumably more secure. > > > > thanks, > > Pino > > > > > > > __ > > 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] [Glance][Security] Secure Hash Algorithm Spec
Thanks Scott, makes sense. On Fri, Sep 29, 2017 at 12:19 PM, Luke Hinds <lhi...@redhat.com> wrote: > > > On Thu, Sep 28, 2017 at 8:38 PM, McClymont Jr, Scott <scott.mcclymont@ > verizonwireless.com> wrote: > >> Hey All, >> >> I've got a spec up for a change I want to implement in Glance for Queens >> to enhance the current checksum (md5) functionality with a stronger hash >> algorithm. I'm going to do this in such a way that it is easily altered in >> the future for new algorithms as they are released. I'd appreciate it if >> someone on the security team could look it over and comment. Thanks. >> >> Review: https://review.openstack.org/#/c/507568/ >> >> > +1 , thanks for undertaking this work. Strong support from the security > projects side. > > Would be good to see all projects move on from MD5 use now, its been known > to be insecure for sometime and clashes with FIPS-142 compliance. > > > >> -- >> Scott McClymont >> Sr. Software Engineer >> Verizon Cloud Platform >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [api-wg][glance] call for comments on Glance spec for Queens
Thank you Brian! +1 for solving this, I left my comments in review. On Fri, Sep 29, 2017 at 12:00 PM, Luke Hinds <lhi...@redhat.com> wrote: > > > On Fri, Sep 29, 2017 at 3:08 AM, Brian Rosmaita < > rosmaita.foss...@gmail.com> wrote: > >> Hello API WG, >> >> I've got a patch up for a proposal to fix OSSN-0075 by introducing a >> new policy. There are concerns that this will introduce an >> interoperability problem in that an API call that works in one >> OpenStack cloud may not work in other OpenStack clouds. As author of >> the spec, I think this is an OK trade-off to fix the security issue, >> but not all members of the Glance community agree, so we're trying to >> get some wider perspective. We'd appreciate it if some API-WG members >> could take a look and leave a comment: >> >> https://review.openstack.org/#/c/468179/ >> >> If you could respond by Tuesday 3 October, that would give us time to >> get this worked out before the spec freeze (6 October). >> >> thanks, >> brian >> >> > +1 for efforts to take this forward and find a resolution, from a security > standpoint it would be good to see this solved. > > Luke > > __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Janney 2.0 "Data Protection in OpenStack" Summary Presentation
Hi Kaitlin, great to hear this, thank you. However I can't access document you have referenced, 'aplweb.jhuapl.edu’s server DNS address could not be found.' On Thu, Sep 21, 2017 at 7:15 PM, Farr, Kaitlin M. <kaitlin.f...@jhuapl.edu> wrote: > Hi everyone, > > I will be presenting a recap of the "Data Protection in OpenStack" > presentation from IEEE CLOUD on Monday, September 25th at 4 PM in Central > Spark. The OpenStack team wrote the paper, and the funding came from the > Janney 2.0 "Engage" awards. > > https://aplweb.jhuapl.edu/news/Pages/JanneyTalks_KaitlineFarr.aspx > > Thanks! > > Kaitlin > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Glare][TC][All] Past, Present and Future of Glare project
Barbican already supports multiple secret storage backends [1] and most likely adding Keycloak's one [2] should be possible. [1] https://docs.openstack.org/project-install-guide/key-manager/draft/barbican-backend.html [2] https://github.com/jpkrohling/secret-store On Tue, Jun 27, 2017 at 10:42 AM, Thierry Carrez <thie...@openstack.org> wrote: > Mikhail Fedosin wrote: > > Does the above mean you are implementing a share secret > storage > > solution or that you are going to use an existing solution > like > > Barbican that does that? > > > > Sectets is a plugin for Glare we developed for Nokia CloudBand > > platform, and they just decided to opensource it. It doesn't > > use Barbican, technically it is oslo.versionedobjects class. > > > > Sorry to hear that you opted not to use Barbican. > > > > I think it's only because Keycloak integration is required by Nokia's > > system and Barbican doesn't support it. > > Any technical reason why it couldn't be added to Barbican ? Any chance > Keycloak integration could be added as a Castellan backend ? Secrets > management is really one of those things that should *not* be reinvented > in every project. It is easier to get wrong than people think, and you > end up having to do security audits on 10 repositories instead of one. > > -- > Thierry Carrez (ttx) > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [all] Policy rules for APIs based on "domain_id"
Hello Valeriy, agree, that would be very useful. I think that this deserves attention and cross project discussion. Maybe a community goal process [2] is a valid path forward in this regard. [2] https://governance.openstack.org/tc/goals/ On Tue, Jun 20, 2017 at 11:15 AM, Valeriy Ponomaryov < vponomar...@mirantis.com> wrote: > Hello OpenStackers, > > Wanted to pay some attention to one of restrictions in OpenStack. > It came out, that it is impossible to define policy rules for API services > based on "domain_id". > As far as I know, only Keystone supports it. > > So, it is unclear whether it is intended or it is just technical debt that > each OpenStack project should > eliminate? > > For the moment, I filed bug [1]. > > Use case is following: usage of Keystone API v3 all over the cloud and > level of trust is domain, not project. > > And if it is technical debt how much different teams are interested in > having such possibility? > > [1] https://bugs.launchpad.net/nova/+bug/1699060 > > -- > Kind Regards > Valeriy Ponomaryov > www.mirantis.com > vponomar...@mirantis.com > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [tc][appcat] The future of the App Catalog
signed Zaqar URL with a subscription triggering a Mistral workflow, > > and I've started working on a POC.) > > > > What triggers the boot to kick over the bucket full of golf balls > though? > > > > Considering computers as some-how inherently 'better' or 'worse' than > > > some of the 'cloud-native' concepts is hog wash. Different users have > > > different needs. As Clint points out - kubernetes needs to run > > > _somewhere_. CloudFoundry needs to run _somewhere_. So those are at > > > least two other potential users who are not me and my collection of > > > things I want to run that want to run in computers. > > > > I think we might be starting to talk about different ideas. The whole > > VMs vs. containers fight _is_ hogwash. You're right to call it out as > > such. We hear far too much about it, and it's totally unfair to the > > folks who work on the VM side. But that isn't what this discussion is > about. > > > > Google has done everyone a minor disservice by appropriating the term > > "cloud-native" and using it in a context such that it's effectively been > > redefined to mean "containers instead of VMs". I've personally stopped > > using the term because it's more likely to generate confusion than > clarity. > > > > What "cloud-native" used to mean to me was an application that knows > > it's running in the cloud, and uses the cloud's APIs. As opposed to > > applications that could just as easily be running in a VPS or on bare > > metal, but happen to be running in a VM provisioned by Nova. > > > > +1 for "apps that know they're in the cloud", and further apps that know > how to talk to their cloud. > > And also +1 for listening to folks who want a little more help in > interacting with their cloud from inside their VMs. If I've squelched > anyone in the past, well, times have changed. Let's get this done. > > Also, thanks Zane, for actually answering directly the main question. > What would we change in Nova? We'd make it easier for vms to interact > with their cloud. > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [tc][appcat] The future of the App Catalog
wrappers around Docker containers). Traffic stats show around 100 visits > >> per week, 75% of which only read the index page. > >> > >> In parallel, Docker developed a pretty successful containerized > >> application marketplace (the Docker Hub), with hundreds of thousands of > >> regularly-updated apps. Keeping the App Catalog around (including its > >> thinly-wrapped Docker container Murano packages) make us look like we > >> are unsuccessfully trying to compete with that ecosystem, while > >> OpenStack is in fact completely complementary. > >> > >> In the past we have retired projects that were dead upstream. The App > >> Catalog is not in this case: it has an active maintenance team, which > >> has been successfully maintaining the framework and accepting > >> applications. If we end up retiring the App Catalog, it would clearly > >> not be a reflection on that team performance, which has been stellar > >> despite limited resources. It would be because the beta was arguably not > >> successful in building an active marketplace of applications, and > >> because its continuous existence is not a great fit from a strategy > >> perspective. Such removal would be a first for our community, but I > >> think it's now time to consider it. > >> > >> Before we discuss or decide anything at the TC level, I'd like to > >> collect everyone thoughts (and questions) on this. Please feel free to > >> reply to this thread (or reach out to me privately if you prefer). > Thanks > >> ! > > > > > > Mirantis' position is that the App Catalog was a good idea, but we agree > > with you that other application repositories like DockerHub and Quay.io > are > > both more useful and more actively used. > > > > The OpenStack App Catalog does indeed seem to unnecessarily compete with > > those application repositories, and we would support its retirement if > that > > is what the community would like to do. We'll provide resources and help > in > > winding anything down if needed. > > > > Best, > > -jay > > > > > > > __ > > 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 > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [tc][appcat][murano][app-catalog] The future of the App Catalog
decide anything at the TC level, I'd like to > > collect everyone thoughts (and questions) on this. Please feel free to > > reply to this thread (or reach out to me privately if you prefer). > Thanks ! > > As the former PTL I am obviously a little bit biased. Even though my > focus has shifted and I've stepped away from the app catalog, I had > been spending a lot of time trying to figure out how to make > applications an easy to run thing on OpenStack. I've also been trying > to find a community of people who are looking for that, and it doesn't > seem like they've materialized; possibly because that community > doesn't exist? Or else we just haven't been able to figure out where > they're hiding ;) > > The one consideration that is pretty important here is what this would > mean to the Murano community. Those folks have been contributed time > and resources to the app catalog project. They've also standardized > on the app catalog as the distribution mechanism, intending to make > the app catalog UI a native component for Murano. We do need to make > sure that if the app catalog is retired, it doesn't hamper or impact > people who have already deployed Murano and are counting on finding > the apps in the app catalog. > > -Christopher > > > > > -- > > Thierry Carrez (ttx) > > > > > __ > > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef
> nicely and a nice process there, but sort of forgotten about all that > being quite useless if no one can consume them (without going through > much pain or paying a vendor). > > This has or has IMHO been a factor in why certain are companies (and the > people they support) are exiting openstack and just going elsewhere. > > I personally don't believe fixing this is 'let the market forces' figure > it out for us (what a slow & horrible way to let this play out; I'd > almost rather go pull my fingernails out). I do believe it will require > making opinionated decisions which we have all never been very good at. > > __ > 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 > > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [openstack-ansible] Ocata deployed on CentOS 7!
Major, thanks for sharing this! On Thu, Jan 19, 2017 at 5:24 PM, Major Hayden <ma...@mhtx.net> wrote: > On 01/19/2017 10:04 AM, Adam Heczko wrote: > > BTW are you implying that Ubuntu LTS is unstable or not stable enough to > run OpenStack? > > I think that it would be valuable if you could share more details in > this regard, point to Ubuntu specific bugs etc. > > Hey Adam, > > One of the bigger issues (as Ian noted) is a performance regression[0] > that seems to impact Ansible[1] heavily. That one is being worked now. > > I have a scratch sheet of some things that are broken in 16.04.1 that I > still need to open bugs for: > > * Xenial installer fails if server is UEFI capable, but > the installer is run in legacy mode > > * 14.04 to 16.04 upgrades on UEFI capable servers fail if > 14.04 was installed in legacy/BIOS mode > > * systemd-networkd 229 has a bug where bridges can't have a > VLAN interface attached > > * Kernel panics on Dell PowerEdge R710 when the server is fairly > loaded with LXC containers > > I'm still working on reducing some of these bugs down into something > tangible but I hope to do that soon. > > [0] https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695 > [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 > > -- > Major Hayden > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [openstack-ansible] Ocata deployed on CentOS 7!
Hi Major, great news indeed. BTW are you implying that Ubuntu LTS is unstable or not stable enough to run OpenStack? I think that it would be valuable if you could share more details in this regard, point to Ubuntu specific bugs etc. Thanks. On Thu, Jan 19, 2017 at 2:58 PM, Sean M. Collins <s...@coreitpro.com> wrote: > That is great news! Congrats! > > -- > Sean M. Collins > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [security] [telemetry] How to handle security bugs
Hi Julien, I think that you should follow this [1] workflow. TL;DR: Pls make sure that if the bug is serious make it private on LP so that only core team members can access it and propose patches. Please do not send patches to Gerrit review queue but rather attach it to LP bug ticket and discuss there. Contact VMT members to get more details on how to get Telemetry project covered by VMT. [1] https://security.openstack.org/vmt-process.html On Tue, Jan 17, 2017 at 1:26 PM, Julien Danjou <jul...@danjou.info> wrote: > Hi, > > I've asked on #openstack-security without success, so let me try here > insteead: > > We, Telemetry, have a security bug and we're not managed by VMT, any > hint as how to handle our bug? Or how to get covered by VMT? > > Cheers, > -- > Julien Danjou > /* Free Software hacker >https://julien.danjou.info */ > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] - Nominate Maksim Malchuk to Fuel Library Core
Although I'm not Fuel core, +1 from me to Maksim. Maksim is not only excellent engineer but also very friendly and helpful folk. On Tue, Jun 28, 2016 at 12:19 PM, Georgy Kibardin <gkibar...@mirantis.com> wrote: > +1 > > On Tue, Jun 28, 2016 at 1:12 PM, Kyrylo Galanov <kgala...@mirantis.com> > wrote: > >> +1 >> >> On Tue, Jun 28, 2016 at 1:16 AM, Matthew Mosesohn <mmoses...@mirantis.com >> > wrote: >> >>> +1. Maksim is an excellent reviewer. >>> >>> On Mon, Jun 27, 2016 at 6:06 PM, Alex Schultz <aschu...@mirantis.com> >>> wrote: >>> > +1 >>> > >>> > On Mon, Jun 27, 2016 at 9:04 AM, Bogdan Dobrelya < >>> bdobre...@mirantis.com> >>> > wrote: >>> >> >>> >> On 06/27/2016 04:54 PM, Sergii Golovatiuk wrote: >>> >> > I am very sorry for sending without subject. I am adding subject to >>> >> > voting and my +1 >>> >> >>> >> +1 from my side! >>> >> >>> >> > >>> >> > -- >>> >> > Best regards, >>> >> > Sergii Golovatiuk, >>> >> > Skype #golserge >>> >> > IRC #holser >>> >> > >>> >> > On Mon, Jun 27, 2016 at 4:42 PM, Sergii Golovatiuk >>> >> > <sgolovat...@mirantis.com <mailto:sgolovat...@mirantis.com>> wrote: >>> >> > >>> >> > Hi, >>> >> > >>> >> > I would like to nominate Maksim Malchuk to Fuel-Library Core >>> team. >>> >> > He’s been doing a great job so far [0]. He’s #2 reviewer and #2 >>> >> > contributor with 28 commits for last 90 days [1][2]. >>> >> > >>> >> > Fuelers, please vote with +1/-1 for approval/objection. Voting >>> will >>> >> > be open until July of 4th. This will go forward after voting is >>> >> > closed if there are no objections. >>> >> > >>> >> > Overall contribution: >>> >> > [0] http://stackalytics.com/?user_id=mmalchuk >>> >> > Fuel library contribution for last 90 days: >>> >> > [1] >>> >> > <http://stackalytics.com/report/contribution/fuel-library/90> >>> http://stackalytics.com/report/contribution/fuel-library/90 >>> >> > http://stackalytics.com/report/users/mmalchuk >>> >> > List of reviews: >>> >> > [2] >>> >> > >>> https://review.openstack.org/#/q/reviewer:%22Maksim+Malchuk%22+status:merged,n,z >>> >> > -- >>> >> > Best regards, >>> >> > Sergii Golovatiuk, >>> >> > Skype #golserge >>> >> > IRC #holser >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> __ >>> >> > 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 >>> >> > >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Bogdan Dobrelya, >>> >> Irc #bogdando >>> >> >>> >> >>> __ >>> >> 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 >>> > >>> >>> >>> __ >>> 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 >> >> > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] [Shotgun] Decoupling Shotgun from Fuel
t; > >>>> > Yet another thing should be taken into account. > >>>> > One of Shotgun features is diagnostic report > >>>> > that could then be attached to bugs to identify > >>>> > the content of env. This report could also be > >>>> > used to reproduce env and then fight a bug. > >>>> > I'd like we to have this kind of report. > >>>> > Is it possible to implement such a feature > >>>> > using Ansible? If yes, then let's switch to Ansible > >>>> > as soon as possible. > >>>> > > >>>> > > >>>> > > >>>> > Vladimir Kozhukalov > >>>> > > >>>> > On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky > >>>> > <ikalnit...@mirantis.com> wrote: > >>>> > Neil Jerram wrote: > >>>> > > But isn't Ansible also over-complicated for just running commands > >>>> > > over SSH? > >>>> > > >>>> > It may be not so "simple" to ignore that. Ansible has a lot of > modules > >>>> > which might be very helpful. For instance, Shotgun makes a database > >>>> > dump and there're Ansible modules with the same functionality [1]. > >>>> > > >>>> > Don't think I advocate Ansible as a replacement. My point is, let's > >>>> > think about reusing ready solutions. :) > >>>> > > >>>> > - igor > >>>> > > >>>> > > >>>> > [1]: http://docs.ansible.com/ansible/list_of_database_modules.html > >>>> > > >>>> > On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram > >>>> > <neil.jer...@metaswitch.com> wrote: > >>>> > > > >>>> > > FWIW, as a naive bystander: > >>>> > > > >>>> > > On 30/03/16 11:06, Igor Kalnitsky wrote: > >>>> > >> Hey Fuelers, > >>>> > >> > >>>> > >> I know that you probably wouldn't like to hear that, but in my > >>>> > >> opinion > >>>> > >> Fuel has to stop using Shotgun. It's nothing more but a command > >>>> > >> runner > >>>> > >> over SSH. Besides, it has well known issues such as retrieving > >>>> > >> remote > >>>> > >> directories with broken symlinks inside. > >>>> > > > >>>> > > It makes sense to me that a command runner over SSH might not need > >>>> > > to be > >>>> > > a whole Fuel-specific component. > >>>> > > > >>>> > >> So I propose to find a modern alternative and reuse it. If we > stop > >>>> > >> supporting Shotgun, we can spend extra time to focus on more > >>>> > >> important > >>>> > >> things. > >>>> > >> > >>>> > >> As an example, we can consider to use Ansible. It should not be > >>>> > >> tricky > >>>> > >> to generate Ansible playbook instead of generating Shotgun one. > >>>> > >> Ansible is a well known tool for devops and cloud operators, and > >>>> > >> they > >>>> > >> we will only benefit if we provide possibility to extend > diagnostic > >>>> > >> recipes in usual (for them) way. What do you think? > >>>> > > > >>>> > > But isn't Ansible also over-complicated for just running commands > >>>> > > over SSH? > >>>> > > > >>>> > > Neil > >>>> > > > >>>> > > > >>>> > > > >>>> > > > __ > >>>> > > 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 > >>>> > > >>>> > > >>>> > > __ > >>>> > 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 > >>>> > >>>> -- > >>>> Tomasz 'Zen' Napierala > >>>> Product Engineering - Poland > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > __ > >>>> 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 > >>> > >> > >> > >> > __ > >> 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 > > > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] [Plugins] Netconfig tasks changes
Thanks Alex, will experiment with it once again although AFAIR it doesn't solve thing I'd like to do. I'll come later to you in case of any questions. On Wed, May 25, 2016 at 10:00 AM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hey Adam, > > in Fuel we have the following option (checkbox) on Network Setting tab: > > Assign public network to all nodes > When disabled, public network will be assigned to controllers only > > So if you uncheck it (by default it's unchecked) then public network and > 'br-ex' will exist on controllers only. Other nodes won't even have > "Public" network on node interface configuration UI. > > Regards, > Alex > > On Wed, May 25, 2016 at 9:43 AM, Adam Heczko <ahec...@mirantis.com> wrote: > >> Hello Alex, >> I have a question about the proposed changes. >> Is it possible to introduce new vlan and associated bridge only for >> controllers? >> I think about DMZ use case and possibility to expose public IPs/VIP and >> API endpoints on controllers on a completely separate L2 network (segment >> vlan/bridge) not present on any other nodes than controllers. >> Thanks. >> >> On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <adide...@mirantis.com >> > wrote: >> >>> Hi folks, >>> >>> we had to revert those changes [0] since it's impossible to propery >>> handle two different netconfig tasks for multi-role nodes. So everything >>> stays as it was before - we have single task 'netconfig' to configure >>> network for all roles and you don't need to change anything in your >>> plugins. Sorry for inconvenience. >>> >>> Our current plan for fixing network idempotency is to keep one task but >>> change 'cross-depends' parameter to yaql_exp. This will allow us to use >>> single 'netconfig' task for all roles but at the same time we'll be able to >>> properly order it: netconfig on non-controllers will be executed only >>> aftetr 'virtual_ips' task. >>> >>> Regards, >>> Alex >>> >>> [0] https://review.openstack.org/#/c/320530/ >>> >>> >>> On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko < >>> adide...@mirantis.com> wrote: >>> >>>> Hi all, >>>> >>>> please be aware that now we have two netconfig tasks (in Fuel 9.0+): >>>> >>>> - netconfig-controller - executed on controllers only >>>> - netconfig - executed on all other nodes >>>> >>>> puppet manifest is the same, but tasks are different. We had to do this >>>> [0] in order to fix network idempotency issues [1]. >>>> >>>> So if you have 'netconfig' requirements in your plugin's tasks, please >>>> make sure to add 'netconfig-controller' as well, to work properly on >>>> controllers. >>>> >>>> Regards, >>>> Alex >>>> >>>> [0] https://bugs.launchpad.net/fuel/+bug/1541309 >>>> [1] >>>> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z >>>> >>> >>> >>> >>> __ >>> 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 >>> >>> >> >> >> -- >> Adam Heczko >> Security Engineer @ Mirantis Inc. >> >> __ >> 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] [Plugins] Netconfig tasks changes
Hello Alex, I have a question about the proposed changes. Is it possible to introduce new vlan and associated bridge only for controllers? I think about DMZ use case and possibility to expose public IPs/VIP and API endpoints on controllers on a completely separate L2 network (segment vlan/bridge) not present on any other nodes than controllers. Thanks. On Wed, May 25, 2016 at 9:28 AM, Aleksandr Didenko <adide...@mirantis.com> wrote: > Hi folks, > > we had to revert those changes [0] since it's impossible to propery handle > two different netconfig tasks for multi-role nodes. So everything stays as > it was before - we have single task 'netconfig' to configure network for > all roles and you don't need to change anything in your plugins. Sorry for > inconvenience. > > Our current plan for fixing network idempotency is to keep one task but > change 'cross-depends' parameter to yaql_exp. This will allow us to use > single 'netconfig' task for all roles but at the same time we'll be able to > properly order it: netconfig on non-controllers will be executed only > aftetr 'virtual_ips' task. > > Regards, > Alex > > [0] https://review.openstack.org/#/c/320530/ > > > On Thu, May 19, 2016 at 2:36 PM, Aleksandr Didenko <adide...@mirantis.com> > wrote: > >> Hi all, >> >> please be aware that now we have two netconfig tasks (in Fuel 9.0+): >> >> - netconfig-controller - executed on controllers only >> - netconfig - executed on all other nodes >> >> puppet manifest is the same, but tasks are different. We had to do this >> [0] in order to fix network idempotency issues [1]. >> >> So if you have 'netconfig' requirements in your plugin's tasks, please >> make sure to add 'netconfig-controller' as well, to work properly on >> controllers. >> >> Regards, >> Alex >> >> [0] https://bugs.launchpad.net/fuel/+bug/1541309 >> [1] >> https://review.openstack.org/#/q/I229957b60c85ed94c2d0ba829642dd6e465e9eca,n,z >> > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] [Shotgun] Decoupling Shotgun from Fuel
Osquery [1] could also be considered as providing a lot of useful informations in a convenient way. [1] https://osquery.io/ On Wed, Mar 30, 2016 at 3:20 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Igor, > > I can not agree more. Wherever possible we should > use existent mature solutions. Ansible is really > convenient and well known solution, let's try to > use it. > > Yet another thing should be taken into account. > One of Shotgun features is diagnostic report > that could then be attached to bugs to identify > the content of env. This report could also be > used to reproduce env and then fight a bug. > I'd like we to have this kind of report. > Is it possible to implement such a feature > using Ansible? If yes, then let's switch to Ansible > as soon as possible. > > > > Vladimir Kozhukalov > > On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > >> Neil Jerram wrote: >> > But isn't Ansible also over-complicated for just running commands over >> SSH? >> >> It may be not so "simple" to ignore that. Ansible has a lot of modules >> which might be very helpful. For instance, Shotgun makes a database >> dump and there're Ansible modules with the same functionality [1]. >> >> Don't think I advocate Ansible as a replacement. My point is, let's >> think about reusing ready solutions. :) >> >> - igor >> >> >> [1]: http://docs.ansible.com/ansible/list_of_database_modules.html >> >> On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram <neil.jer...@metaswitch.com> >> wrote: >> > >> > FWIW, as a naive bystander: >> > >> > On 30/03/16 11:06, Igor Kalnitsky wrote: >> >> Hey Fuelers, >> >> >> >> I know that you probably wouldn't like to hear that, but in my opinion >> >> Fuel has to stop using Shotgun. It's nothing more but a command runner >> >> over SSH. Besides, it has well known issues such as retrieving remote >> >> directories with broken symlinks inside. >> > >> > It makes sense to me that a command runner over SSH might not need to be >> > a whole Fuel-specific component. >> > >> >> So I propose to find a modern alternative and reuse it. If we stop >> >> supporting Shotgun, we can spend extra time to focus on more important >> >> things. >> >> >> >> As an example, we can consider to use Ansible. It should not be tricky >> >> to generate Ansible playbook instead of generating Shotgun one. >> >> Ansible is a well known tool for devops and cloud operators, and they >> >> we will only benefit if we provide possibility to extend diagnostic >> >> recipes in usual (for them) way. What do you think? >> > >> > But isn't Ansible also over-complicated for just running commands over >> SSH? >> > >> > Neil >> > >> > >> > >> __ >> > 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 >> > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] [Openstack] Problem after reboot fuel-master VM
Samer my 2c are: after Fuel node reboot just run 'docker ps -a' to get information if all containers have been already running. On Wed, Mar 30, 2016 at 1:07 PM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Thanks, >Problem solved by magic. It looks like, the nailgun service take some > time to start up in my computer. > > -- > *From: *"Samer Machara" <samer.mach...@telecom-sudparis.eu> > *To: *"OpenStack Development Mailing List" < > openstack-dev@lists.openstack.org> > *Sent: *Wednesday, March 30, 2016 12:39:35 PM > *Subject: *Re: [Fuel] [Openstack] Problem after reboot fuel-master VM > > > Hi Vladimir, > I'm using fuel 7.0, Which log I need to see? > > -- > *From: *"*Vladimir Kuklin* vkuklin at mirantis.com > <openstack-dev%40lists.openstack.org?Subject=Re%3A%20%5Bopenstack-dev%5D%20%5BFuel%5D%20%5BOpenstack%5D%20Problem%20after%20reboot%0A%20fuel-master%20VM=%3CCAHAWLf2-xQ0G-m-ApocgOAVDG1GTEb5F-f7NXoiwN%3DpbCQ3JWA%40mail.gmail.com%3E> > *To: *"OpenStack Development Mailing List" < > openstack-dev@lists.openstack.org> > *Sent: **Wed Mar 30 10:06:22 UTC 2016* > *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM > > Hi, Samer > > It seems that Nailgun has not started. Could you please provide us with the > version of Fuel you are using? You can find logs for nailgun in: > > for <9.0/pre-Mitaka versions > /var/log//nailgun/ > > for current Mitaka: > > /var/log/nailgun/ > > -- > *From: *"Samer Machara" <samer.mach...@telecom-sudparis.eu> > *To: *"OpenStack Development Mailing List" < > openstack-dev@lists.openstack.org> > *Sent: *Wednesday, March 30, 2016 11:38:44 AM > *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM > > Hello, > I have rebooted the "fuel-master" VM and after that, I cannot access the > Fuel UI. What I am missing. Please check the image to see the error. > > Another question, How can I rediscover a node that was removed from > the pool of available nodes, and also add new nodes to the pool. I clone a > fuel-slave node but, it is not recognized by fuel > > Thanks in advance. > > > > > ______ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Single Sign On integration research
Good job Kseniya :) A. On Tue, Mar 8, 2016 at 3:21 PM, Jay Pipes <jaypi...@gmail.com> wrote: > Awesome blogs, Kseniya, thank you for sharing this! :) > -jay > > On 03/08/2016 09:12 AM, Kseniya Tychkova wrote: > >> Hi, >> as you may know currently Keystone supports Single Sign-On (SSO) and as >> I think it is one of the most interesting features in Keystone. >> I've done research on Single Sign-On in Keystone. Practically I just >> tried to set up Keystone in 2 different configuration. >> As a result of my research I have 2 blog posts and I would like to share >> links with you: >> >> *1. Keystone Service Provider with Shibboleth Identity Provider (WebSSO >> profile) >> <http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html >> >*: >> <http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html >> > >> ( >> http://xuctarine.blogspot.ru/2016/02/keystone-service-provider-with.html >> ) >> Post describes how to step-by-step deploy Shibboleth Identity Provider >> with Keystone Service Provider. >> This configuration is interesting because you can easily replace >> Shibboleth Identity Provider >> with any other Identity Provider with SAML support. >> So it is, I think, most popular use case for SSO in Keystone. >> >> *2. How to setup Keystone with Shibboleth (ECP profile): >> < >> http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html >> > >> *( >> >> http://xuctarine.blogspot.ru/2016/02/how-to-setup-keystone-with-shibboleth.html >> ) >> Post describes how to deploy Keystone Identity Provider with Keystone >> Service Provider. >> It is Keystone-to-Keystone configuration and it uses ECP profile >> (Enhanced Client or Proxy) of SAML Protocol. >> A lot of information for this post I took from rodrigods blog >> ( >> http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo >> ). >> >> I hope my posts will help you to deploy/configure SSO or at least will >> be interesting to take a look at SSO feature in Keystone. >> >> Kind regards, Kseniya >> >> >> __ >> 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [kolla][security] Obtaining the vulnerability:managed tag
Hi Steven, I'd like to help you with vulnerability management process of Kolla and become a member of Kolla VMT team. I have experience and expertise in IT security and related to it processes. Best regards, Adam On Tue, Mar 1, 2016 at 5:55 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Core reviewers, > > Please review this document: > > https://github.com/openstack/governance/blob/master/reference/tags/vulnerability_managed.rst > > It describes how vulnerability management is handled at a high level for > Kolla. When we are ready, I want the kolla delivery repos vulnerabilities > to be managed by the VMT team. By doing this, we standardize with other > OpenStack processes for handling security vulnerabilities. > > The first step is to form a kolla-coresec team, and create a separate > kolla-coresec tracker. I have already created the tracker for > kolla-coresec and the kolla-coresec team in launchpad: > > https://launchpad.net/~kolla-coresec > > https://launchpad.net/kolla-coresec > > I have a history of security expertise, and the PTL needs to be on the > team as an escalation point as described in the VMT tagging document > above. I also need 2-3 more volunteers to join the team. You can read the > requirements of the job duties in the vulnerability:managed tag. > > If your interested in joining the VMT team, please respond on this > thread. If there are more then 4 individuals interested in joining this > team, I will form the team from the most active members based upon liberty > + mitaka commits, reviews, and PDE spent. > > Regards > -steve > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core
requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> -- >> >> Kind Regards, >> >> Fedor Zhadaev >> >> >> >> skype: zhadaevfm >> >> IRC: fzhadaev >> >> >> ______ >> 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 >> >> >> >> >> >> -- >> >> Thanks, Ivan Berezovskiy >> >> MOS Puppet Team Lead >> >> at Mirantis <https://www.mirantis.com/> >> >> >> >> slack: iberezovskiy >> >> skype: bouhforever >> >> phone: + 7-960-343-42-46 >> >> >> >> __ >> 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 >> >> > > > -- > Regards, > Sergey Kolekonov > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"
Hello Dmitry, I like this idea and very much appreciate it. +1 from me :) A. On Mon, Dec 7, 2015 at 9:48 PM, Dmitry Mescheryakov < dmescherya...@mirantis.com> wrote: > Hello folks, > > I'd like to request extension of current FFE for the feature [1]. During > the three FFE days we merged the spec [2] after big discussion and made a > couple iterations over the implementation [3]. We had a chat with Bogdan on > how to progress and here are the action items still need to be done: > * part of the change responsible for RabbitMQ policy need to be > upstreamed first to RabbitMQ repo. > * the change needs to be review and merged by our library folks. > > Overall I think that 2-3 more days should be enough to finish it. > > What do you think folks? > > Dmitry > > [1] > https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc > [2] https://review.openstack.org/247517 > [3] https://review.openstack.org/249180 > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [fuel][plugins]Security problem in Fuel 7.0
t;>>> __ >>>> > 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 >>>> >>>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> -- >>> Eugene Korekin >>> Partner Enablement Team Deployment Engineer >>> >>> >>> ______ >>> 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 >>> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> >> __ >> 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > Eugene Korekin > Partner Enablement Team Deployment Engineer > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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-dev] [Fuel] API services available on public VIP
Hello fuelers, today I'd like to raise a questions about Fuel deployment practice related to Public (external) network. Current approach is to expose by default over public IP openstack API endpoints like nova, cinder, glance, neutron etc. These API services are exposed through HAProxy with TLS support, so this approach seems to be relatively secure. OTOH industry practice is to don't expose over public IPs too much and rather rely on user action / decision to expose API access to the public. I'd like to ask for your opinions regarding this topic and approach taken by Fuel. Thank you, -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] Running Fuel node as non-superuser
Dmitry, +1 Do you plan to port your patchset to future Fuel releases? A. On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <dnikis...@mirantis.com> wrote: > Hey guys. > > I've been working on making Fuel not to rely on superuser privileges > at least for day-to-day operations. These include: > a) running Fuel services (nailgun, astute etc) > b) user operations (create env, deploy, update, log in) > > The reason for this is that many security policies simply do not > allow root access (especially remote) to servers/environments. > > This feature/enhancement means that anything that currently is being > run under root, will be evaluated and, if possible, put under a > non-privileged > user. This also means that remote root access will be disabled. > Instead, users will have to log in with "fueladmin" user. > > Together with Omar we've put together a blueprint[0] and a > spec[1] for this feature. I've been developing this for Fuel 6.1, so there > are two patches into fuel-main[2] and fuel-library[3] that can give you an > impression of current approach. > > These patches do following: > - Add fuel-admin-user package, which creates 'fueladmin' > - Make all other fuel-* packages depend on fuel-admin-user > - Put supervisord under 'fueladmin' user. > > Please review the spec/patches and let's have a discussion on the approach > to > this feature. > > Thank you. > > [0] https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser > [1] https://review.openstack.org/243340 > [2] https://review.openstack.org/243337 > [3] https://review.openstack.org/243313 > > -- > Dmitry Nikishov, > Deployment Engineer, > Mirantis, Inc. > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Product] [fuel] Life cycle management use cases
Hi All, in regards to lifecycle management I've just submitted blueprint covering security assessment of OpenStack clouds [0]. Note that it doesn't aim to intersect with Congress project. Congress is focused on 'overlay' or cloud security policy. Nessus integration is 100% oriented towards cloud control plane security, ie. assessment of controller and hypervisor hosts. [0] https://blueprints.launchpad.net/fuel/+spec/fuel-provision-nessus On Fri, Oct 16, 2015 at 2:50 AM, Mike Scherbakov <mscherba...@mirantis.com> wrote: > Hi Shamail, > thank you for letting me know. I didn't come through the page when I was > googling. > > We are collecting use cases though for underlay, so it's more relevant for > such projects as Fuel, TripleO, Puppet OpenStack; than for VM, DB, etc. > related management. > > If you have any work started on underlay, I'll be more than happy to > collaborate. > > PS. Meanwhile we've got lots of feedback in the etherpad, thanks all! > > On Wed, Oct 14, 2015 at 3:34 PM Shamail <itzsham...@gmail.com> wrote: > >> Great topic... >> >> Please note that the Product WG[1] also has a user story focused on >> Lifecycle Management. While FUEL is one aspect of the overall workflow, we >> would also like the team to consider project level enhancements (e.g. >> garbage collection inside the DB). >> >> The Product WG would welcome your insights on lifecycle management >> tremendously. Please help by posting comments to our existing user >> story[2]. >> >> >> [1] https://wiki.openstack.org/wiki/ProductTeam >> [2] >> http://specs.openstack.org/openstack/openstack-user-stories/user-stories/draft/lifecycle_management.html >> >> Thanks, >> Shamail >> >> > On Oct 14, 2015, at 5:04 PM, Mike Scherbakov <mscherba...@mirantis.com> >> wrote: >> > >> > Hi fuelers, >> > as we all know, Fuel lacks many of life cycle management (LCM) use >> cases. It becomes a very hot issue for many of our users, as current LCM >> capabilities are not very rich. >> > >> > In order to think how we can fix it, we need to collect use cases >> first, and prioritize them if needed. So that whatever a change in >> architecture we are about to make, we would need to ensure that we meet LCM >> use cases or have a proposal how to close it in a foreseeable future. >> > >> > I started to collect use cases in the etherpad: >> https://etherpad.openstack.org/p/lcm-use-cases. >> > >> > Please contribute in there. >> > >> > Thank you, >> > -- >> > Mike Scherbakov >> > #mihgen >> > >> __ >> > 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 >> ___ >> Product-wg mailing list >> product...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg >> > -- > Mike Scherbakov > #mihgen > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] FW: [Fuel] 8.0 Region name support / Multi-DC
feature: give user ability to *specify >> Region name in UI.* >> >> >> >> Region name is already in every puppet module, so we just need to add >> this to UI. >> >> >> >> Do we have smth already? >> >> >> >> More general question: What are our plans in regards Multi-DC? >> >> >> >> Thanks >> >> >> >> -- >> >> Roman Sokolkov, >> >> Deployment Engineer, >> >> Mirantis, Inc. >> Skype rsokolkov, >> rsokol...@mirantis.com >> >> -- >> >> Chris Clason >> >> Director of Architecture >> >> ccla...@mirantis.com >> >> Mobile: +1.408.409.0295 >> >> __ >> 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 >> >> > > > -- > Roman Sokolkov, > Deployment Engineer, > Mirantis, Inc. > Skype rsokolkov, > rsokol...@mirantis.com > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Apache2 vs uWSGI vs ...
nd uwsgi and it seemed to work fine, though I haven't done any sort >> >> of load testing. I'd encourage folks to give it a shot. :) >> >> >> >> >> >> Again, switching web servers is as likely to introduce as to solve >> >> problems. If there are performance issues: >> >> >> >> 1. Idenitfy what causes them >> >> 2. Change configuration settings to deal with them >> >> 3. Fix upstream bugs in the underlying system. >> >> >> >> >> >> Keystone is not about performance. Keystone is about security. The >> cloud >> >> is designed to scale horizontally first. Before advocating switching >> to a >> >> difference web server, make sure it supports the technologies required. >> >> >> >> >> >> 1. TLS at the latest level >> >> 2. Kerberos/GSSAPI/SPNEGO >> >> 3. X509 Client cert validation >> >> 4. SAML >> >> >> >> OpenID connect would be a good one to add to the list; Its been >> requested >> >> for a while. >> >> >> >> If Keystone is having performance issues, it is most likely at the >> >> database layer, not the web server. >> >> >> >> >> >> >> >> "Programmers waste enormous amounts of time thinking about, or worrying >> >> about, the speed of noncritical parts of their programs, and these >> attempts >> >> at efficiency actually have a strong negative impact when debugging and >> >> maintenance are considered. We should forget about small efficiencies, >> say >> >> about 97% of the time: premature optimization is the root of all evil. >> Yet >> >> we should not pass up our opportunities in that critical 3%." >> --Donald >> >> Knuth >> >> >> >> >> >> >> >> Of course, uwsgi can also be ran behind Apache2, if you'd prefer. >> >> >> >> gunicorn[2] is another good option that may be worth investigating; I >> >> personally don't have any experience with it, but I seem to remember >> >> hearing it has good eventlet support. >> >> >> >> // jim >> >> >> >> [0] https://uwsgi-docs.readthedocs.org/en/latest/ >> >> [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html >> >> [2] http://gunicorn.org/ >> >> >> >> >> __ >> >> 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 >> >> >> > >> > >> > >> > -- >> > Yours Faithfully, >> > Vladimir Kuklin, >> > Fuel Library Tech Lead, >> > Mirantis, Inc. >> > +7 (495) 640-49-04 >> > +7 (926) 702-39-68 >> > Skype kuklinvv >> > 35bk3, Vorontsovskaya Str. >> > Moscow, Russia, >> > www.mirantis.com >> > www.mirantis.ru >> > vkuk...@mirantis.com >> > >> > >> __ >> > 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, >> Alexander Makarov, >> Senior Software Developer, >> >> Mirantis, Inc. >> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia >> >> Tel.: +7 (495) 640-49-04 >> Tel.: +7 (926) 204-50-60 >> >> Skype: MAKAPOB.AJIEKCAHDP >> >> __ >> 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Apache2 vs uWSGI vs ...
OK, sorry I mixed up nginx and uwsgi :) A. On Fri, Sep 25, 2015 at 2:54 PM, David Stanek <dsta...@dstanek.com> wrote: > > On Fri, Sep 25, 2015 at 8:25 AM Adam Heczko <ahec...@mirantis.com> wrote: > >> Are we discussing mod_wsgi and Keystone or OpenStack as a general? >> If Keystone specific use case, then probably Apache provides broadest >> choice of tested external authenticators. >> I'm not against uwsgi at all, but to be honest expectation that nginx >> could substitute Apache in terms of authentication providers is simply >> unrealistic. >> > > uwsgi isn't a replacement for Apache. It's a replacement for mod_wsgi. It > just so happens that it does let you use user web servers if that's what > your usecase dictates. > > As a Keystone developer I don't want to tell deployers that they have to > use Apache. It should be their choice. Since Apache is the most common web > server in our community I think we should continue to provide example > configurations and guidance for it. > > > -- David > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] Bugs which we should accept in 7.0 after Hard Code Freeze
Hi, I'd like to ask for fixing these security related bugs in stable/7.0 branch: https://bugs.launchpad.net/fuel/+bug/1496407 https://bugs.launchpad.net/fuel/+bug/1488732 Both are fuel-library related tasks, it is Apache2 and NTPD configuration lifting. Thanks, Adam On Tue, Sep 15, 2015 at 12:19 AM, Mike Scherbakov <mscherba...@mirantis.com> wrote: > Thanks Andrew. > Team, if there are any disagreements - let's discuss it. Otherwise, I > think we should be just strict and follow defined process. We can deliver > high priority bugfixes in updates channel later if needed. > > I hope that reasoning is clear for everything. Every bugfix has a > potential to break something. It's basically a risk. > > On Mon, Sep 14, 2015 at 8:57 AM Andrew Maksimov <amaksi...@mirantis.com> > wrote: > >> Hi Everyone! >> >> I would like to reiterate the bugfix process after Hard Code Freeze. >> According to our HCF definition [1] we should only merge fixes for >> *Critical* bugs to *stable/7.0* branch, High and lower priority bugs >> should NOT be accepted to *stable/7.0* branch anymore. >> Also we should accept patches for critical bugs to *stable/7.0* branch >> only after the corresponding patchset with same ChangeID was accepted into >> master. >> >> [1] - https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze >> >> Regards, >> Andrey Maximov >> Fuel Project Manager >> __ >> 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 >> > -- > Mike Scherbakov > #mihgen > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] Remove MOS DEB repo from master node
round providing the >> tools >> >>>> for a user to get up and running in a timely fashion. Perhaps >> providing an >> >>>> net-only iso and an all-included iso would be a better solution so >> people >> >>>> will have their expectations properly set up front? >> >>> >> >>> >> >>> Let me explain why I think having local MOS mirror by default is bad: >> >>> 1) I don't see any reason why we should treat MOS repo other way than >> >>> all other online repos. A user sees on the settings tab the list of >> repos >> >>> one of which is local by default while others are online. It can make >> user a >> >>> little bit confused, can't it? A user can be also confused by the >> fact, that >> >>> some of the repos can be cloned locally by fuel-createmirror while >> others >> >>> can't. That is not straightforward, NOT fuel-createmirror UX. >> >> >> >> >> >> >> >> I agree. The process should be the same and it should be just another >> >> repo. It doesn't mean we can't include a version on an ISO as part of a >> >> release. Would it be better to provide the mirror on the ISO but not >> have >> >> it enabled by default for a release so that we can gather user >> feedback on >> >> this? This would include improved documentation and possibly allowing >> a user >> >> to choose their preference so we can collect metrics? >> >> >> >> >> >>> 2) Having local MOS mirror by default makes things much more >> convoluted. >> >>> We are forced to have several directories with predefined names and >> we are >> >>> forced to manage these directories in nailgun, in upgrade script, >> etc. Why? >> >>> 3) When putting MOS mirror on ISO, we make people think that ISO is >> equal >> >>> to MOS, which is not true. It is possible to implement really flexible >> >>> delivery scheme, but we need to think of these things as they are >> >>> independent. >> >> >> >> >> >> >> >> I'm not sure what you mean by this. Including a point in time copy on >> an >> >> ISO as a release is a common method of distributing software. Is this a >> >> messaging thing that needs to be addressed? Perhaps I'm not familiar >> with >> >> people referring to the ISO as being MOS. >> >> >> >> >> >>> For large users it is easy to build custom ISO and put there what they >> >>> need but first we need to have simple working scheme clear for >> everyone. I >> >>> think dealing with all repos the same way is what is gonna makes >> things >> >>> simpler. >> >>> >> >> >> >> >> >> Who is going to build a custom ISO? How does one request that? What >> >> resources are consumed by custom ISO creation process/request? Does >> this >> >> scale? >> >> >> >> >> >>> >> >>> This thread is not about internet connectivity, it is about aligning >> >>> things. >> >>> >> >> >> >> You are correct in that this thread is not explicitly about internet >> >> connectivity, but they are related. Any changes to remove a local >> repository >> >> and only provide an internet based solution makes internet connectivity >> >> something that needs to be included in the discussion. I just want to >> make >> >> sure that we properly evaluate this decision based on end user >> feedback not >> >> because we don't want to manage this from a developer standpoint. >> > >> > >> > >> > +1, whatever the changes is, please keep Fuel as a tool that can deploy >> > without Internet access, this is part of reason that people like it and >> it's >> > better that other tools. >> >> >> >> >> >> -Alex >> >> >> >> >> >> >> __ >> >> 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 >> >> >> > >> > >> > >> > -- >> > Yaguang Tang >> > Technical Support, Mirantis China >> > >> > Phone: +86 15210946968 >> > >> > >> > >> > >> __ >> > 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 >> > > > > -- > Yaguang Tang > Technical Support, Mirantis China > > *Phone*: +86 15210946968 > > > > __ > 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 > > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] Remove MOS DEB repo from master node
t; continue with that, we need to do a better job around providing the > tools > >>>> for a user to get up and running in a timely fashion. Perhaps > providing an > >>>> net-only iso and an all-included iso would be a better solution so > people > >>>> will have their expectations properly set up front? > >>> > >>> > >>> Let me explain why I think having local MOS mirror by default is bad: > >>> 1) I don't see any reason why we should treat MOS repo other way than > >>> all other online repos. A user sees on the settings tab the list of > repos > >>> one of which is local by default while others are online. It can make > user a > >>> little bit confused, can't it? A user can be also confused by the > fact, that > >>> some of the repos can be cloned locally by fuel-createmirror while > others > >>> can't. That is not straightforward, NOT fuel-createmirror UX. > >> > >> > >> > >> I agree. The process should be the same and it should be just another > >> repo. It doesn't mean we can't include a version on an ISO as part of a > >> release. Would it be better to provide the mirror on the ISO but not > have > >> it enabled by default for a release so that we can gather user feedback > on > >> this? This would include improved documentation and possibly allowing a > user > >> to choose their preference so we can collect metrics? > >> > >> > >>> 2) Having local MOS mirror by default makes things much more > convoluted. > >>> We are forced to have several directories with predefined names and we > are > >>> forced to manage these directories in nailgun, in upgrade script, etc. > Why? > >>> 3) When putting MOS mirror on ISO, we make people think that ISO is > equal > >>> to MOS, which is not true. It is possible to implement really flexible > >>> delivery scheme, but we need to think of these things as they are > >>> independent. > >> > >> > >> > >> I'm not sure what you mean by this. Including a point in time copy on an > >> ISO as a release is a common method of distributing software. Is this a > >> messaging thing that needs to be addressed? Perhaps I'm not familiar > with > >> people referring to the ISO as being MOS. > >> > >> > >>> For large users it is easy to build custom ISO and put there what they > >>> need but first we need to have simple working scheme clear for > everyone. I > >>> think dealing with all repos the same way is what is gonna makes things > >>> simpler. > >>> > >> > >> > >> Who is going to build a custom ISO? How does one request that? What > >> resources are consumed by custom ISO creation process/request? Does this > >> scale? > >> > >> > >>> > >>> This thread is not about internet connectivity, it is about aligning > >>> things. > >>> > >> > >> You are correct in that this thread is not explicitly about internet > >> connectivity, but they are related. Any changes to remove a local > repository > >> and only provide an internet based solution makes internet connectivity > >> something that needs to be included in the discussion. I just want to > make > >> sure that we properly evaluate this decision based on end user feedback > not > >> because we don't want to manage this from a developer standpoint. > > > > > > > > +1, whatever the changes is, please keep Fuel as a tool that can deploy > > without Internet access, this is part of reason that people like it and > it's > > better that other tools. > >> > >> > >> -Alex > >> > >> > >> > __ > >> 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 > >> > > > > > > > > -- > > Yaguang Tang > > Technical Support, Mirantis China > > > > Phone: +86 15210946968 > > > > > > > > > __ > > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] SSL keys saving
Hi Evgeniy, what you've proposed is all right, although it adds some overhead for certificate provisioning. In fact, to do it right we should probably define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. Today I want to discuss the way we save SSL keys for Fuel environments. As you maybe know we have 2 ways to get a key: a. Generate it by Fuel (self-signed certificate will be created in this case). In this case we will generate private key, csr and crt in a pre-deployment hook on master node and then copy keypair to the nodes which needed it. b. Get a pre-generated keypair from user. In this case user should create keypair by himself and then upload it through Fuel UI settings tab. In this case keypair will be saved in nailgun database and then will serialized into astute.yaml on cluster nodes, pulled from it by puppet and saved into a file. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 1.2. It brings problems for implementation in other different places - for example, we need to get certificate for properly run OSTF tests and now we should implement two different ways to deliver that certificate to OSTF container. The same for fuel-cli - we should somehow get certificate from DB and place it in FS to use it. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 3. If keypair data serializes into astute.yaml it means than that data automatically will be fetched when diagnostic snapshot will created. So in some cases in can lead to security vulnerability, or we will must to write another crutch to cut it out of diagnostic snapshot. So I propose to get rid of saving keypair in nailgun database and implement a way to always saving it to local FS on master node. We need to implement next items: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Fuel] SSL keys saving
Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind of overhead if designed from the beginning. If there are some HTTP authentication/CSR request/key management mechanisms already in place, of course there is no overhead. Regards, A. On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L e...@mirantis.com wrote: Hi Adam, I'm not sure if understand you correctly, what do you mean by overhead for certificate provisioning? We already have all the mechanisms in place in order to provision certificates, the point is currently with user's certificates we work in absolutely different way and store them in absolutely different place. And this way leads to huge problems. Thanks, On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko ahec...@mirantis.com wrote: Hi Evgeniy, what you've proposed is all right, although it adds some overhead for certificate provisioning. In fact, to do it right we should probably define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to specific nodes by Astute. So UI should send the file to specific URL, Nginx should be configured to send auth request to backend, after request is authorised, Nginx should save the file into predefined directory, the same which we use for autogenerated certificates, in this case such tool as OSTF can take certificates from a single place. Thanks, On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. Today I want to discuss the way we save SSL keys for Fuel environments. As you maybe know we have 2 ways to get a key: a. Generate it by Fuel (self-signed certificate will be created in this case). In this case we will generate private key, csr and crt in a pre-deployment hook on master node and then copy keypair to the nodes which needed it. b. Get a pre-generated keypair from user. In this case user should create keypair by himself and then upload it through Fuel UI settings tab. In this case keypair will be saved in nailgun database and then will serialized into astute.yaml on cluster nodes, pulled from it by puppet and saved into a file. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 1.2. It brings problems for implementation in other different places - for example, we need to get certificate for properly run OSTF tests and now we should implement two different ways to deliver that certificate to OSTF container. The same for fuel-cli - we should somehow get certificate from DB and place it in FS to use it. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 3. If keypair data serializes into astute.yaml it means than that data automatically will be fetched when diagnostic snapshot will created. So in some cases in can lead to security vulnerability, or we will must to write another crutch to cut it out of diagnostic snapshot. So I propose to get rid of saving keypair in nailgun database and implement a way to always saving it to local FS on master node. We need to implement next items: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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
Re: [openstack-dev] [Fuel] SSL keys saving
Hi Stanislav, agree that unification is very useful and it is right direction. While designing implementation changes please remember that we should serve cases: 1). There could be multiple environments served by one Fuel node. IMO we should prepare a way to have different private key per environment. In some cases private key will be common / shared for all environments, in some cases no. 2). We should remember that there are various X.509 use cases for various OpenStack services. Usually, X.509 is used only for TLS traffic encryption. But in some cases we want to make authentication decision based on X.509 certificate. This is useful for example with libvirt authentication, soon we'll have mechanism for X.509 Keystone authentication. In other words: - we should remember to have consistent naming policy for X.509 certificates storage, and there should be implemented kind of 'per service' certificate directory - X.509 role will vary, depending on service. Sometimes only encryption, sometimes also authentication. 3). Elliptic Curve Cryptography (ECC) support even adds more complexity, as I could imagine a situation where we rely on RSA private keys for some services, and we rely on ECC private keys for others. In fact, IMO we should always create RSA and ECC private key pair per Fuel environment, and then, in Fuel UI provide user an option which type of cryptography (RSA or ECC) use for which service. Or take simplified approach, and during cluster provisioning 'hard code' which type of cryptography (which private key) use globally for all services. Of course scope of implementation to be discussed, the whole X.509 topic is not easy one, and doing thing 'right' could be really time consuming. Just my 2 cents :) On Fri, Aug 21, 2015 at 11:10 AM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi folks. Today I want to discuss the way we save SSL keys for Fuel environments. As you maybe know we have 2 ways to get a key: a. Generate it by Fuel (self-signed certificate will be created in this case). In this case we will generate private key, csr and crt in a pre-deployment hook on master node and then copy keypair to the nodes which needed it. b. Get a pre-generated keypair from user. In this case user should create keypair by himself and then upload it through Fuel UI settings tab. In this case keypair will be saved in nailgun database and then will serialized into astute.yaml on cluster nodes, pulled from it by puppet and saved into a file. Second way has some flaws: 1. We already have some keys for nodes and we store them on master node. Store keys in different places is bad, cause: 1.1. User experience - user should remember that in some cases keys will be store in FS and in some other cases - in DB. 1.2. It brings problems for implementation in other different places - for example, we need to get certificate for properly run OSTF tests and now we should implement two different ways to deliver that certificate to OSTF container. The same for fuel-cli - we should somehow get certificate from DB and place it in FS to use it. 2. astute.yaml is similar for all nodes. Not all of nodes needs to have private key, but now we cannot control this. 3. If keypair data serializes into astute.yaml it means than that data automatically will be fetched when diagnostic snapshot will created. So in some cases in can lead to security vulnerability, or we will must to write another crutch to cut it out of diagnostic snapshot. So I propose to get rid of saving keypair in nailgun database and implement a way to always saving it to local FS on master node. We need to implement next items: - Change UI logic that saving keypair into DB to logic that will save it to local FS - Implement according fixes in fuel-library __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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][Fernet] HA SQL backend for Fernet keys
Hi, I believe that Barbican keystore for signing keys was discussed earlier. I'm not sure if that's best idea since Barbican relies on Keystone authN/authZ. That's why this mechanism should be considered rather as out of band to Keystone/OS API and is rather devops task. regards, Adam On Wed, Aug 5, 2015 at 8:11 AM, joehuang joehu...@huawei.com wrote: Hi, Lance, May we store the keys in Barbican, can the key rotation be done upon Barbican? And if we use Barican as the repository, then it’s easier for Key distribution and rotation in multiple KeyStone deployment scenario, the database replication (sync. or async.) capability could be leveraged. Best Regards Chaoyi Huang ( Joe Huang ) *From:* Lance Bragstad [mailto:lbrags...@gmail.com] *Sent:* Tuesday, August 04, 2015 10:56 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Keystone][Fernet] HA SQL backend for Fernet keys On Tue, Aug 4, 2015 at 9:28 AM, Boris Bobrov bbob...@mirantis.com wrote: On Tuesday 04 August 2015 08:06:21 Lance Bragstad wrote: On Tue, Aug 4, 2015 at 1:37 AM, Boris Bobrov bbob...@mirantis.com wrote: On Monday 03 August 2015 21:05:00 David Stanek wrote: On Sat, Aug 1, 2015 at 8:03 PM, Boris Bobrov bbob...@mirantis.com wrote: Also, come on, does http://paste.openstack.org/show/406674/ look overly complex? (it should be launched from Fuel master node). I'm reading this on a small phone, so I may have it wrong, but the script appears to be broken. It will ssh to node-1 and rotate. In the simplest case this takes key 0 and moves it to the next highest key number. Then a new key 0 is generated. Later there is a loop that will again ssh into node-1 and run the rotation script. If there is a limit set on the number of keys and you are at that limit a key will be deleted. This extra rotation on node-1 means that it's possible that it has a different set of keys than are on node-2 and node-3. You are absolutely right. Node-1 should be excluded from the loop. pinc also lacks -c 1. I am sure that other issues can be found. In my excuse I want to say that I never ran the script and wrote it just to show how simple it should be. Thank for review though! I also hope that no one is going to use a script from a mailing list. What's the issue with just a simple rsync of the directory? None I think. I just want to reuse the interface provided by keystone-manage. You wanted to use the interface from keystone-manage to handle the actual promotion of the staged key, right? This is why there were two fernet_rotate commands issued? Right. Here is the fixed version (please don't use it anyway): http://paste.openstack.org/show/406862/ Note, this doesn't take into account the initial key repository creation, does it? Here is a similar version that relies on rsync for the distribution after the initial key rotation [0]. [0] http://cdn.pasteraw.com/d6odnvtt1u9zsw5mg4xetzgufy1mjua -- Best regards, Boris Bobrov __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] Would people see a value in the cve-check-tool?
Hi Elena, the tool looks very interesting. Maybe try to spread out this proposal also through openstack-security@ ML. BTW, I can't find the wrapper mentioned - am I missing something? Regards, Adam On Mon, Aug 3, 2015 at 11:08 PM, Reshetova, Elena elena.reshet...@intel.com wrote: Hi, We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. The tool is located here: https://github.com/ikeydoherty/cve-check-tool I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). Best Regards, Elena. __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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][Fernet] HA SQL backend for Fernet keys
pushed out to all nodes as 0 first. Don't over think it. Just read http://lbragstad.com/?p=133 and it will remain simple. __ 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 __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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][Fernet] HA SQL backend for Fernet keys
Fine, then this simple bash based solution proposed by Boris [1] LGTM and is not over thinked. Maybe add kind of md5 or sha1 checksum functionality to confirm if keys were rotated correctly and are in sync. [1] http://paste.openstack.org/show/406674/ Regards, Adam On Mon, Aug 3, 2015 at 2:03 PM, David Stanek dsta...@dstanek.com wrote: On Mon, Aug 3, 2015 at 7:14 AM, Davanum Srinivas dava...@gmail.com wrote: agree. Native HA solution was already ruled out in several email threads by keystone cores already (if i remember right). This is a devops issue and should be handled as such was the feedback. I'm sure you are right. I'm not sure why we would want to add that much complexity into Keystone. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [fuel] OS_SERVICE_TOKEN usage in Fuel
__ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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] [Cinder] encryption is not supported in ceph volume
Indeed, it works only for iSCSI Cinder backends. I believe there are at least two ways in which volume encryption for Ceph could be achieved: - by implementing encryption at librbd level (user space) - rewriting Ceph's Cinder plugin, to attach RBD images not through libvirt/librbd but for accessing Ceph use native Linux kernel RBD driver and stack LUKS atop of RBD (device-mapper way) Regards, Adam On Thu, Jul 30, 2015 at 8:02 AM, Li, Xiaoyan xiaoyan...@intel.com wrote: Hi all, I created an encryption type, and create a volume in Ceph with the volume type. cinder encryption-type-create But failed to attach it to a VM. The error message shows that no device_path in connection_info. ^[[01;31m2015-07-30 05:55:57.117 TRACE oslo_messaging.rpc.dispatcher ^[[01;35m^[[00mself.symlink_path = connection_info['data']['device_path']^M ^[[01;31m2015-07-30 05:55:57.117 TRACE oslo_messaging.rpc.dispatcher ^[[01;35m^[[00mKeyError: 'device_path' Two questions: 1. Is it not supported to create volume in Ceph with encrypted volume type? 2. If yes, should we prohibit to create a Ceph volume with encrypted volume type. Best wishes Lisa __ 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 -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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-dev] [Fuel] Add support for Keystone's Fernet encryption keys management: initialization, rotation
Hi Folks, Keystone supports Fernet tokens which have payload encrypted by AES 128 bit key. Although AES 128 bit key looks secure enough for most OpenStack deployments [2], one may would like to rotate encryption keys according to already proposed 3 step key rotation scheme (in case keys get compromised or organizational security policy requirement). Also creation and initial AES key distribution between Keystone HA nodes could be challenging and this complexity could be handled by Fuel deployment tool. In regards to Fuel, I'd like to: 1. Add support for initializing Keystone's Fernet signing keys to Fuel during OpenStack cluster (Keystone) deployment 2. Add support for rotating Keystone's Fernet signing keys to Fuel according to some automatic schedule (for example one rotation per week) or triggered from the Fuel web user interface or through Fuel API. These two capabilities will be implemented in Fuel by related blueprint [1]. [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support [2] http://www.eetimes.com/document.asp?doc_id=1279619 Regards, -- Adam Heczko Security Engineer @ Mirantis Inc. __ 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
