Extending a security perimeter into a tenant-specific public cloud partition
Methods, systems, and computer program products for executing trusted software components in public computing clouds. Verifiably authentic software components are installed into a tenant partition of a multi-tenant public cloud-based environment. To do so, a software component installer is configured to install registered software components into the tenant partition. Installer processing includes (1) obtaining a component-specific token for a software component wherein the component-specific token is specific to both the software component to be installed and a particular tenant, and (2) installing the software component on behalf of the given tenant in the multi-tenant public cloud-based environment. Prior to executing the underlying code of the tenant-specific software component, the software component is authenticated with a component registry using the component-specific token. Additional trusted components are installed based on demand from within the tenant partition. No user or administrator intervention is needed and no credentials are hard-coded into the software components.
1. A non-transitory computer readable medium having stored thereon a sequence of instructions which, when stored in memory and executed by a processor cause the processor to perform acts for loading one or more registered software components in a multi-tenant public cloud-based environment the acts comprising:
instantiating, into a tenant partition of a multi-tenant public cloud architecture, a software component installer that is configured to install a software component into the tenant partition by:
obtaining a component-specific token for the software component to be installed into the multi-tenant public cloud architecture, wherein the component-specific token is specific to the software component to be installed and a given tenant; and
installing the software component on behalf of the given tenant in the multi-tenant public cloud architecture; and
authenticating the software component with a component registry, wherein the software component is authenticated by using the component-specific token for the software component.
2. The non-transitory computer readable medium of claim 1 ,
wherein the software component installer accesses the component registry to request generation of the component-specific token,
the multi-tenant public cloud architecture is communicably connected to an external computing environment,
the external computing environment includes the component registry and a trusted service, and
the trusted service retrieves the component-specific token from the component registry and sends the component-specific token to the software component installer to authenticate the software component from within the multi-tenant public cloud architecture.
3. The non-transitory computer readable medium of claim 1 , wherein the software component installer loads the software component as an authenticated software component into the multi-tenant public cloud architecture.
4. The non-transitory computer readable medium of claim 1 , further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of:
establishing a mutual trust relationship between the software component and a further software component by:
generating a further component-specific token for the further software component to be installed into the multi-tenant public cloud architecture, wherein the further component-specific token is specific to the further software component and the given tenant; and
installing the further software component on behalf of the given tenant in the multi-tenant public cloud architecture.
5. The non-transitory computer readable medium of claim 4 , further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of authenticating the further software component with the component registry, wherein the further software component is authenticated by using the further component-specific token for the further software component.
6. The non-transitory computer readable medium of claim 4 , further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of carrying out a communication exchange between the software component and the further software component, wherein the communication exchange includes sharing of the further component-specific token.
7. The non-transitory computer readable medium of claim 4 , wherein the software component and the further software component carry out a communication exchange by executing trust protocol code.
8. A method for loading one or more registered software components in a multi-tenant public cloud architecture comprising:
instantiating, into a tenant partition of a multi-tenant public cloud architecture, a software component installer that is configured to respond to a command to install a software component into the tenant partition by:
obtaining a component-specific token for the software component to be installed into the multi-tenant public cloud architecture, wherein the component-specific token is specific to the software component to be installed and a given tenant; and
installing the software component on behalf of the given tenant in the multi-tenant public cloud architecture; and
authenticating the software component with a component registry, wherein the software component is authenticated by using the component-specific token for the software component.
9. The method of claim 8 , wherein the software component installer accesses the component registry to request generation of the component-specific token,
the multi-tenant public cloud architecture is communicably connected to an external computing environment,
the external computing environment includes the component registry and a trusted service, and
the trusted service retrieves the component-specific token from the component registry and sends the component-specific token to the software component installer to authenticate the software component from within the multi-tenant public cloud architecture.
10. The method of claim 8 , wherein the software component installer loads the software component as an authenticated software component into the multi-tenant public cloud architecture.
11. The method of claim 8 , further comprising:
establishing a mutual trust relationship between the software component and a further software component by:
generating a further component-specific token for the further software component to be installed into the multi-tenant public cloud architecture, wherein the further component-specific token is specific to the further software component and the given tenant; and
installing the further software component on behalf of the given tenant in the multi-tenant public cloud architecture.
12. The method of claim 11 , further comprising authenticating the further software component with the component registry, wherein the further software component is authenticated by using the further component-specific token for the further software component.
13. The method of claim 11 , further comprising carrying out a communication exchange between the software component and the further software component, wherein the communication exchange includes sharing of the further component-specific token.
14. The method of claim 11 , wherein the software component and the further software component carry out a communication exchange by executing trust protocol code.
15. A system for loading one or more registered software components in a multi-tenant public cloud architecture comprising:
a storage medium having stored thereon a sequence of instructions; and
a processor that executes the sequence of instructions to cause the processor to perform acts comprising,
instantiating, into a tenant partition of a multi-tenant public cloud architecture, a software component installer that is configured to respond to a command to install a software component into the tenant partition by:
obtaining a component-specific token for the software component to be installed into the multi-tenant public cloud architecture, wherein the component-specific token is specific to the software component to be installed and a given tenant; and
installing the software component on behalf of the given tenant in the multi-tenant public cloud architecture; and
authenticating the software component with a component registry, wherein the software component is authenticated by using the component-specific token for the software component.
16. The system of claim 15 , wherein
the software component installer accesses the component registry to request generation of the component-specific token,
the multi-tenant public cloud architecture is communicably connected to an external computing environment,
the external computing environment includes the component registry and a trusted service, and
the trusted service retrieves the component-specific token from the component registry and sends the component-specific token to the software component installer to authenticate the software component from within the multi-tenant public cloud architecture.
17. The system of claim 15 , wherein the software component installer loads the software component as an authenticated software component into the multi-tenant public cloud architecture.
18. The system of claim 15 , further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of:
establishing a mutual trust relationship between the software component and a further software component by:
generating a further component-specific token for a further software component to be installed into the multi-tenant public cloud architecture, wherein the further component-specific token is specific to the further software component and the given tenant; and
installing the further software component on behalf of the given tenant in the multi-tenant public cloud architecture.
19. The system of claim 18 , further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of authenticating the further software component with the component registry, wherein the further software component is authenticated by using the further component-specific token for the further software component.
20. The system of claim 18 , further comprising instructions which, when stored in memory and executed by the processor cause the processor to perform further acts of carrying out a communication exchange between the software component and the further software component, wherein the communication exchange includes sharing of the further component-specific token.
21. The system of claim 18 , wherein the software component and the further software component carry out a communication exchange by executing trust protocol code.