RHEDcloud for AWS Launch Accelerator and Knowledge Transfer Engagement (Provider Candid Cloud)

Provider: Candid Cloud (https://www.candid.cloud)

Contacts: Chris Donahue (Christopher.Donahue@candid.cloud), Steve Wheat (Steve.Wheat@candid.cloud)

 

Executive Summary

What is RHEDcloud?

RHEDcloud is a framework for enterprises to:

  1. Broker AWS accounts, GCP projects, and Microsoft Azure Subscriptions for their internal customers,

  2. Implement enterprise security controls through policies, active detection, and automated remediation, and

  3. Integrate cloud assets deeply into their enterprise identity management, authentication, authorization, and network security infrastructure.

The RHEDcloud Project works collaboratively with its members to assess risk for each cloud service and to specify controls in the form of policies and detective controls with automated remediation. As a result of the collaboration of its diverse institutional membership, RHEDcloud reduces the investment for all members, accelerates time-to-implement, and improves the quality of risk assessments and controls.

A one-page executive introduction as well as a comprehensive description of the type of service one can implement with RHEDcloud are available on the RHEDcloud Project wiki. On-demand demonstrations are available on the RHEDcloud Project web site.

Launch Engagement

The goal of this engagement is to get a new site up and running with RHEDcloud and familiarize the team with RHEDcloud so they may use and operate RHEDcloud effectively. This engagement is designed to accelerate the delivery of RHEDcloud for an organization by bringing in RHEDcloud and DevOps expert services. RHEDcloud for AWS services can be executed to include knowledge-sharing activities with defined team members if desired.

This engagement includes a license for the current version of the Candid Terraform Configs for RHEDcloud, which accelerate the initial setup of the RHEDcloud services and enables on-demand spin-up / spin-down of environments resulting in reduced on-going costs of operations. Upon completion of this engagement, the site will have two working environments of RHEDcloud for AWS:

  1. Test environment for accepting and testing updates from the RHEDcloud project or new site-specific features

  2. Production environment to run the service

The environments are integrated with the RHEDcloud project infrastructure and several of the organization’s own enterprise systems.

Candid maintains and provides support for the Candid Terraform Configs for RHEDcloud.

Additional Services and Fees for Consideration:

  • The Candid Terraform Configs for RHEDcloud support four environments (development, test, staging, and production), so sites can spin up additional environments later if needed or they can be added to this engagement at an additional charge if the site knows in advance that they will need more that two environments.

  • Updates and support for the Candid Terraform Configs are available for an additional annual subscription fee.

  • Sites may also choose to have UNICON run RHEDcloud for them in which case support, maintenance, and operations of RHEDcloud are included in that service. For more on UNICON’s managed service offering see the UNICON Managed Services section below.

Networking Strategies

This engagement includes the setup of one of three RHEDcloud network provisioning architectures:

  1. Fully automated site-to-site VPN provisioning between AWS VPCs and an on-premises network using Cisco ASR 1000 series routers

  2. Associating newly provisioned VPCs with an existing AWS Transit Gateway that implements site-to-site connectivity

  3. Associating newly provisioned VPCs with an AWS Transit Gateway and Security VPC that implements cloud-based NextGen firewalls

The cost of these options vary as described in the Network Connectivity section below.

Integrations

This engagement does not include new custom integrations with a site’s enterprise infrastructure. Some sites will require new or additional integrations with their enterprise infrastructure. For example, RHEDcloud presently supports NetIQ and Grouper as Identity Management Systems, Shibboleth as a SAML2 single sign-on solution, and a directory accessible via LDAP protocols.

If your site requires one or more of the integrations outlined within the section entitled Additional Integrations below, this integration work can be included as part of the engagement scope for the defined corresponding fee.

Additionally, integrations with presently unsupported infrastructure can be implemented at an additional charge and contributed back to the RHEDcloud Project if the organization desires to expand the list of infrastructure RHEDcloud supports.

Goals, Tasks, and Cost

  1. Set up the AWS test and production master accounts and linked account #1 in the production series that will host all Beanstalk environments, RDS, Amazon MQ, and other infrastructure (30 hours):

    1. The following are required:

      1. RHEDcloud AWS Account Service (Account Metadata Repository and Provisioning)

      2. RHEDcloud Console for AWS (Account, VPC, Service, Network, Provisioning, and Notification Management)

      3. RHEDcloud Landing Page for AWS (Launch page with links into the AWS Console, RHEDcloud Console, Service Request System, AWS Service Inventory and Risk Assessments, etc.)

      4. Security Risk Detection Service (Security Overwatch deployed with any or all of the existing detectors developed by the RHEDcloud project)

      5. Temporary Key Issuance (TKI) Serivce (Accelerates and Simplifies User Access without Long-lived Credentials)

      6. IDM Service (Exposes Roles and Role Assignments/Memberships to the Other Services listed here---presently implemented for NetIQ, but also implementing for Grouper and others)

      7. Directory Service (Exposes an organization’s person search features to the other services listed here)

      8. Financial Account System Service (Exposes financial account system numbers to the rest of these applications and services for validation)

      9. Network Operations Service (Network Automation for Site-to-Site VPN and Static NAT)

    2. The following are optional and require 20 more hours added to this engagement if the site chooses to deploy them (depending on what the site is doing and what network, firewall, and other infrastructure they have):

      1. Cisco ASR Service (Router-level automation for Site-to-Site VPN and Static NAT---presently implemented for Cisco ASR routers using Netconf/Yang, but could be extended to other equipment and standards)

      2. Elastic IP Service (Orchestrates On-Prem Static NAT for the Cloud)

      3. Firewall Service (Exposes On-prem and Cloud-based Firewall rules for VPCs---presently implemented for Palo Alto firewalls, but could be extended to others)

  2. Implement the site’s deploy-only pipelines in AWS CodeCommit and AWS CodeDeploy for the site to deploy TEST and PROD environments that pull from the master RHEDcloud repositories. Test and deploy all pipelines (40 hours)

    1. Required deploy-only repos and pipelines

      1. RHEDcloud AWS Account Service

      2. RHEDcloud Console for AWS

      3. RHEDcloud Landing Page for AWS

      4. RHEDcloud Security Risk Detection Service

      5. RHEDcloud TKI Service

      6. RHEDcloud TKI Client

      7. RHEDcloud IDM Service

      8. RHEDcloud Directory Service

      9. RHEDcloud Account CloudFormation Templates

      10. RHEDcloud Type 1 VPC Template

      11. RHEDcloud Standard Service Control Policies

      12. Financial Account Service

      13. RHEDcloud Network Operations Service

    2. Optional repos and pipelines (depending on what the site is doing and what network, firewall, and other infrastructure they have)

      1. RHEDcloud Cisco ASR Service

      2. RHEDcloud Firewall Service

      3. RHEDcloud Elastic IP Service

  3. Deploy and implement network configuration and automation for the site’s selected network automation approach (40-60 hours, depending on which of the following three strategies is selected)

    1. Site-to-site VPN between AWS VPCs and an on-premises network using Cisco ASR 1000 series routers (60 hours)

    2. Associating newly provisioned VPCs with an existing AWS Transit Gateway that implements site-to-site connectivity (60 hours)

    3. Associating newly provisioned VPCs with an AWS Transit Gateway and Security VPC that implements cloud-based NextGen firewalls (40 hours)

  4. Perform training and knowledge transfer on RHEDcloud account series, pipelines, and environment administration (40 hours)

    1. Demonstrate the purpose and function of all of the RHEDcloud for AWS middleware and serverless infrastructure

    2. Demonstrate the purpose and function of RHEDcloud AWS master accounts and account series

  5. Project management, coordination, and scheduling (20 hours)

Total hours: 170 - 190 hours

Approximate Cost: $42,500 - $47,500

Additional Integrations

There are five major integrations to perform when implementing RHEDcloud. There are:

  1. The AWS Console, RHEDcloud Console, and RHEDcloud Temporary Key Issuance (TKI) Service should all use the same single sign-on (SSO) infrastructure. The RHEDcloud Project has implemented SSO for these components using Shibboleth, which is an implementation of SAML2. If a site uses a SAML2 identity and service provider architecture, RHEDcloud can be readily adapted to the new SAML2 implementation. If the site uses some other single sign-on infrastructure, the site should plan to work with Candid to modify these applications. (Estimated cost to implement with a non-SAML2 SSO -$15,000)

  2. Exposing group or role management in the identity management system (IDM) as a web service, so that the RHEDcloud Console and automated account provisioning can interact with identity management. The RHEDcloud Project has already developed provider implementations for NetIQ and Grouper. If a site uses an IDM other than NetIQ or Grouper, the site should plan to work with Candid to implement a new IDM provider for the RHEDcloud IDM Service. (Estimated cost to implement a new IDM provider - $12,000)

  3. Exposing person lookup as a web service. The RHEDcloud Project has already implemented a person lookup provider for LDAP that is configurable. If a site has an LDAP directory, this existing person looking service will either work or can be easily customized. If a site does not have an LDAP directory, the site should plan to work with Candid to implement a new provider for the RHEDcloud LDS Service. (Estimated cost to implement a new person lookup - $5,000)

  4. Exposing financial account number data as a web service, so that RHEDcloud applications and services can determine if the financial system account numbers to which AWS accounts are charged are valid initially and remain valid over time. RHEDcloud has implemented a service to expose PeopleSoft financial account numbers with a customizable query. Sites that do not use PeopleSoft could potentially use this customizable validation query with their own financial system or a new implementation may be required. (Estimated cost to implement a new financial account number validation - $5,000)

  5. Adapting the central billing to financial system feed to load the consolidated billing information into the enterprise financial system. Most enterprise financial systems ingest files for charges from vendors to reflect charges, and the RHEDcloud to finance system interface seeks to leverage one of those existing feeds to load AWS transactions into the financial system. Typically, this work involves identifying an existing file format to leverage and then adjusting the jobs that produce the file feed to match the targeted format. (Estimated cost to adjust the financial system billing feed and test - $5,000)

Prerequisites

There are several prerequisites to starting work on this engagement, including having all desired AWS master accounts and initial linked accounts in place as well as specific network infrastructure. These are:

  1. AWS accounts must exist and be available to the project team. Two accounts will be needed per account series desired---one master account and one linked account to serve as the first account in the series. Most sites will want to implement two account series for a test and production environment, so four accounts will be needed to start.

  2. 50 distribution lists for each account series to serve as the primary e-mail address for each new account. For example, existing sites use series like aws-account-1@emory.edu, aws-account-2@emory.edu, … and aws-test-1@emory.edu, aws-test-2@emory.edu, … to provide e-mail addresses for their accounts. The membership of these distribution lists is generally managed by IDM to match list of users of each account. Note that with many of these e-mail systems provisioning of these distribution lists can be automated as part of the automated provisioning flow, but just to get started it is recommended that 50 of these distribution lists per account series are manually created and automated provisioning can then be addressed later in the provisioning flow.

  3. Network strategy for on-premises to AWS connectivity be selected and be ready for implementation at the site.

  4. If the site prefers Bitbucket and Bitbucket Pipelines over AWS CodeCommit and CodeDeploy, a Bitbucket account will be required to begin setting up the sites deploy-only pipelines.

Getting Started

To get started just complete the brief pre-implementation questionnaire and send it to Chris Donahue (Christopher.Donahue@candid.cloud) and Steve Wheat (Steve.Wheat@candid.cloud). They will take your response and prepare a customized estimate and statement of work for you based on your responses.

UNICON Managed Services

UNICON is developing a managed service to operate and monitor RHEDcloud. UNICON can also help sites accept and test new features and versions of RHEDcloud to keep current with RHEDcloud Project advancements.

[UNICON to add more here]