DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to communication received on 09/17/2025. Claims 1-20 are pending of which claims 1, 3, 4, 8, 11, 12, 16, and 19 are amended
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 5, 8, 9, 12, 13,16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Jahner US 2018/0083937, and further in view of Tamir US 2024/0086550, Enomoto US 2024/0143404 Gilpin 2018/0316676 and Blomquist, Secret Management in a Multicloud Kubernetes Environment.
Regarding claims 1, 8 and 16, Jahner teaches a method, system and non-transitory CRM when executed by a processor for managing security in application deployment, comprising: determining, by a deployment manager, an application definition for an application, the application definition having: (1) an application definition name(deployment director managing deployments for applications where such deployments have a secret set with a secrets name(i.e. application definition name) and secret scope(i.e. application definition), the scope defining one or more key value pairs for secrets in that scope, ¶s 3,4)
[0003] Systems, methods, and computer program products for credential management are described. An application deployment system receives a deployment manifest for deploying an application in a cloud computing environment. A deployment director of the application deployment system determines a resource to be used by the application. The deployment director determines, from the deployment manifest, an identifier, e.g., a name, of credentials for accessing the resource. The deployment director requests the credentials from a credential manager of the application deployment system. Upon receiving the credentials, the deployment director modifies the deployment manifest by replacing the identifier with the received credentials. The application deployment system deploys the application using the modified deployment manifest and then deletes the modified deployment manifest.
[0004] In general, one innovative aspect of the subject matter described in this specification can be embodied an application deployment system that includes a credential manager and a deployment director. The credential manager includes one or more computers programmed to perform secret management operations. The secret management operations include receiving, from a first user device, a secret, the secret including a secret name, a secret type, a secret scope, and a secret value; and storing the secret value in a secret database that corresponds to the secret type. The secret value includes one or more credentials, one or more certificates, or one or more security keys. The deployment director includes one or more computers programmed to perform application deployment operations. The application deployment operations include receiving, from a second user device, a deployment manifest for deploying an application on a cloud-based computing platform. The second user device can be the same as the first user device, or different from the first user device. The application deployment operations include identifying, from the deployment manifest, the secret scope and a link to the credential manager, and identifying the secret type and secret name from the deployment manifest, the secret type and secret name being associated with a resource of the cloud-based computing platform. The application deployment operations include submitting, to the credential manager according to the link, a get secret request, the get secret request including the secret scope, secret type and secret name, and receiving, from the credential manager, the secret value corresponding to the secret name in the secret scope, the secret value being retrieved by the credential manager from the secret database corresponding to the secret type. The application deployment operations include modifying the deployment manifest, including replacing the secret name in the deployment with the secret value received from the credential manager. The application deployment operations include deploying the application on a cloud-based computing platform according to the modified deployment manifest, including allowing the application to access the resource of the cloud-based computing platform using the secret value.
transmitting, by the deployment manager, the secret to a namespace controller(secrets are set into placed into a secrets database via the secrets manager(i.e.namespace controller) using put calls, ¶s28,53)
[0028] Listing 1 illustrates an example API method for storing secret values using a “put” call. The API method has parameters specifying a host name for storing the secret values, a path for storing the secret values, and a secret name. The API method can also have parameters specifying a scope, e.g., “deployment,” in which the secret applies, a secret type, e.g., “static-value” or “SSH,” and the secret values. In this example, the secret values include a user name and password. The API allows devices or processes to set secret values programmatically.
[0053] FIG. 3 is a block diagram illustrating example namespaces 302 of secrets stored in a secret database 210. As disclosed above, the secrets include secret names and corresponding secret values. Each secret name is in a respective namespace, and is associated with a secret type. A scope that can be an arbitrarily created namespace. Scoping the secret names can avoid collisions of common secret names in the namespaces 302 between systems and system groups.
storing, by the namespace controller, the secret in a path in a secrets manager at a path (secrets are written into database using put calls, ¶27 )
[0027] The application deployment system 204 can receive the secret values through a credentials API or through a user interface. The API includes a “put” method for setting secret values. The secret values can be associated with a secret name. Example credential API method and CLI commands for setting secret values are provided below in Listing 1 and Listing 2.
TABLE-US-00001 Listing 1: Example API for Setting Secret Values PUT: [host]/[path]/[secret name] { “scope”: [scope name], “secret-type”: [secret type], “values”: { “user”:[user name], “password”:[password] } }
[0028] Listing 1 illustrates an example API method for storing secret values using a “put” call. The API method has parameters specifying a host name for storing the secret values, a path for storing the secret values, and a secret name. The API method can also have parameters specifying a scope, e.g., “deployment,” in which the secret applies, a secret type, e.g., “static-value” or “SSH,” and the secret values. In this example, the secret values include a user name and password. The API allows devices or processes to set secret values programmatically.
retrieving, by a deployment service, the secret from the secrets manager at the path(deployment system queries secretes databased for secrets values corresponding to secrets specified in manifest, retrieval is performed using get calls ¶62)
[0062] The deployment director then modifies (408) the deployment manifest. Modifying the deployment manifest includes replacing each of the one or more secret names in the deployment manifest with a corresponding secret value received from the credential manager. In case the secret value is generated by the credential manager, the deployment director replaces the secret name with the generated by the credential manager.
[0063] The deployment director provisions (410) the resource for the application using the modified deployment manifest. In provisioning the resource, the deployment director creates a service instance for consumption by the application. The deployment director then binds the resource to the service instance. The service instance can include, for example, a virtual machine in which the application executes. Binding the resource to the service instance can include providing references and credentials for accessing the resource, e.g., addresses and ports of databases, database names, user names and passwords, to the virtual machine. The deployment manifest can be stored on disk. The modified deployment manifest can be stored in memory. The deployment director can delete the modified deployment manifest after the provisioning.
receiving, by the deployment manager from the deployment service, a request to deploy the application at the destination using the source repository, and the secret(deployer provisions service/application using deployment manifest that contain populated secret values, ¶s 62,63)
[0062] The deployment director then modifies (408) the deployment manifest. Modifying the deployment manifest includes replacing each of the one or more secret names in the deployment manifest with a corresponding secret value received from the credential manager. In case the secret value is generated by the credential manager, the deployment director replaces the secret name with the generated by the credential manager.
[0063] The deployment director provisions (410) the resource for the application using the modified deployment manifest. In provisioning the resource, the deployment director creates a service instance for consumption by the application. The deployment director then binds the resource to the service instance. The service instance can include, for example, a virtual machine in which the application executes. Binding the resource to the service instance can include providing references and credentials for accessing the resource, e.g., addresses and ports of databases, database names, user names and passwords, to the virtual machine. The deployment manifest can be stored on disk. The modified deployment manifest can be stored in memory. The deployment director can delete the modified deployment manifest after the provisioning.
authorizing, by the deployment manager, the request using the secret; and(secrets contain credentials that authenticates and allows for deployment of service, ¶43)
[0043] Upon receiving each command described above, the application deployment system 204 performs corresponding operations. For example, upon receiving the command for deploying application, the application deployment system 204 configures a service instance according to a deployment manifest. The deployment director 102 authenticates with the credential manager using information in the deployment manifest that references a credential manager, for example, as described above in reference to Listing 7.
deploying, by the deployment manager…. the application at the destination using the source repository(application/service is provisioned, ¶63).
[0063] The deployment director provisions (410) the resource for the application using the modified deployment manifest. In provisioning the resource, the deployment director creates a service instance for consumption by the application. The deployment director then binds the resource to the service instance. The service instance can include, for example, a virtual machine in which the application executes. Binding the resource to the service instance can include providing references and credentials for accessing the resource, e.g., addresses and ports of databases, database names, user names and passwords, to the virtual machine. The deployment manifest can be stored on disk. The modified deployment manifest can be stored in memory. The deployment director can delete the modified deployment manifest after the provisioning.
Jahner teaches registering secrets and retrieving secrets as part of the process of service deployment. Jahner teaches generating a secret but does not specifically teach the secret is generated from the application definition. Thus, Jahner does not teach generating, by the deployment manager, a secret specific to the application definition. Tamir in the same field of endeavor as the invention teaches a zero trust application development and deployment system. Tamir teaches generating a secret but does not specifically teach the secret is generated from the application definition
[0014] Zero-trust cloud deployment methods, devices, and systems described herein address the aforementioned trust issues by creating a vault that protect secrets in the cloud. In some embodiments, the vault is created by locking down a virtual machine deployed in the cloud and encrypting secrets stored in the virtual machine. When deploying a virtual machine in the cloud environment, the cloud provider uploads physical files as well as metadata files describing the logical virtual machine (VM) metadata, e.g., instance identifier (ID), creation date, and/or modification date, etc. Such deployment metadata change with each and every deployment, e.g., each cloning and every request for a new mount of files. Accordingly, such metadata are both unique per physical file and immutable. Utilizing at least a portion of the deployment metadata, secrets are encrypted using a key derived from the deployment metadata. Accordingly, with the secrets being protected by the key, the secrets are accessible within the virtual machine but are inaccessible from outside the virtual machine, thus establishing zero-trust of any user from outside the virtual machine, even users with administrative privileges.
[0063] In some embodiments, the encryptor 850 is configured to encrypt secrets stored in the cloud within each virtual machine, e.g., encrypting codes, data, and/or metadata stored in the persistent memory of the hardware hosting the virtual machines. In some embodiments, at least a portion of the metadata include deployment metadata of virtual machines, where the deployment metadata for a respective virtual machine change with each deployment of the respective deployment metadata. To that end, the encryptor 850 includes a set of instructions 851a and heuristics and metadata 851b. In some embodiments, the encryptor 850 includes codes (e.g., the codes 122 in FIG. 1 and/or an application corresponding to at least a subset of the codes) that are executable on a respective virtual machine, e.g., as a container and configured to encrypt the secrets stored in the respective virtual machine.
[0064] In some embodiments, the deployment unit 860 is configured to deploy virtual machines using the deployment metadata, where the deployment includes loading secrets encrypted by the encryptor 850 to the respective deployed virtual machine in the cloud. To that end, the deployment unit 860 includes a set of instructions 861a and heuristics and metadata 861b. In some embodiments, to deploy the virtual machines, the deployment unit 860 follows the steps illustrated in FIG. 4 to securely load stored secrets from deployment repository 403 to the cloud.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner with generation of secrets from deployment metadata(i.e. deployment manifest parameter) as taught by Tamir. The reason for this modification would be to provide an alternate data set for generating secrets involving simple substitution that results in a predictable results.
The combination of Jahner/Tamir do not specifically teach the application definition having (2) a project name, (3) a source repository, (4) a destination, (5) an environment, (6) a role, and (7) a policy associated with the role, deploying, by the deployment manager assuming the role the application at the destination using the source repository. Enomoto in the same field of endeavor teaches a CI/CD system for workload deployment. Enomoto teaches the definition having (2) a project name, (3) a source repository, (4) a destination, (5) an environment, (6) a role, and (7) a policy associated with the role,
[0026] When the workload deployment system 102 receives a workload deployment request from an operator device 104, as noted above, the request may identify the workload within a source environment (e.g., a test environment), and the destination environment(s) (e.g., production environments) into which the workload is to be deployed. In some examples, workload deployment requests received from the operator device also may include data identifying the configuration variables associated with a configuration (and/or any other attribute) that can be used for deployment. For instance, configuration variables may include any selection made by an operator or any input provided during the configuration and/or deployment of a workload into a cloud-based environment (or non-cloud-based computing infrastructure such as datacenter). Examples of configuration variables may include, but are not limited to, account names and/or aliases associated with the environment, the organizations and/or projects associated with the environment, and contact information associated with the environment (e.g., administrator(s), email addresses, etc.). Additional examples of configuration variables may include the type/functionality of the environment (e.g., production or non-production, active or inactive, etc.), and roles associated with the account (e.g., identification of administrators, product developers, etc.). Additional configuration variables may include the specifications for network constructs to be used in the environment, such as the IP addresses and/or configuration data of the virtual private network, routing tables, routing rules, security policies/groups, network access controllers, and/or transit gateway associated with the environment. Additional examples of configuration variables may include data identifying the cloud service provider and/or cloud region for the environment, the continuous integration and continuous deployment (CI/CD) pipeline associated with the environment, the encryption component(s) to be used within the environment, the logging component(s) to be used, and/or any other automation components tools, or services to be used in the environment. It can be understood from the context of this disclosure that the examples of configuration variables described herein are illustrative and non-limiting, and that any attribute of a cloud-based deployment and/or cloud-based computing environment may be represented as configuration variables in some examples.
deploying, by the deployment manager assuming the role the application at the destination using the source repository(identity of user with respect to roles… i.e administrator/developer is determined and permission to perform modification to the network is implemented, ¶28)
[0028] After determining the user identity (and/or user credentials) associated with the workload deployment request, the access verification component 106 may verify that the user (and/or the device, network, etc.) is verified to access the workload 112 and associated objects within the source environment, and to modify/deploy the workload 112 within the destination environment. In some examples, the access verification component 106 may transmit requests to each of the source and destination computing environments, to verify that the user is authorized to perform the required operations within each of the computing environments. Such requests may include invoking APIs provided by the computing environments 114-116 and/or by the cloud service providers 122 to verify user authorization. In other instances, the access verification component 106 may access user lists maintained within the computing environments 114-116 to verify sufficient user authorization.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir with deployment parameters as taught by Enomoto. The reason for this modification would be to provide an alternate data set for generating secrets involving simple substitution that results in a predictable results.
Jahner teaches the use of secret values in authorizing requests to deploy applications(¶4) but does not specifically each such secret values in the form of a API token , thus Jahner does not teach wherein the secret comprises an application programming interface (API) token for authorizing an API call to the deployment manager; configuring, by the namespace controller, a namespace corresponding to the project name to permit the role to perform an action at the namespace in accordance with the policy.
Gilpin in the same field of endeavor as the invention teaches a system for authorization logic for configuration of containerized services(¶58). Gilpin teaches wherein the secret comprises an application programming interface (API) token for authorizing an API call to the deployment manager(API keys act as credentials that associated with certain roles that allow certain actions to be performed based on the role, ¶78,121)
[0078] In some embodiments, an access control system policy may be used to define and implement rules to describe which users and services have privileges (e.g., to access machines and other hosts, or to get secrets like passwords and API keys). A policy may collect a set of records and permissions into a single scoped namespace with a common owner. For example, one or more policies may be stored in an internal and/or external database of access control service 320, access control system 220, or access control service 121. A policy may have standard attributes (e.g., an account, an owner, and an ID) and may have a body element that contains records owned by the policy, and permission and grant elements that apply to the policy records.
[0121] Difficulties can be encountered in connecting commercial web services for hosting applications (e.g., Amazon Elastic Compute Cloud™, or “EC2”). Some implementations of secret rotation can make it simple to use a host production module and/or service along with Amazon™ IAM Instance Roles to enroll machines and govern their roles, SSH permissions, and access to secrets in a given access control system. On the AWS side, each EC2 instance can be launched with an IAM role via EC2 Instance Profile selection. The machine's role may have permission to fetch a host production module token (e.g., from an S3 file). The token can be placed in S3 by one of the rotators discussed herein and updated regularly. The token can also have an IP address or Classless Inter-Domain Routing (CIDR) restriction to further restrict its utilization (e.g., to a specific subnet within an EC2 Virtual Private Cloud (VPC)). Once the instance has fetched the token, it can be presented to the host production module or service, which enrolls the host into a layer configuration (e.g., to govern secrets, SSH, and traffic authorization permissions). The host production module or service can also issue a machine identifier and refresh token (e.g., API key) which the host can use to authenticate itself to the access control system. In this way, Amazon™ IAM and an access control system can work together to ensure that actions performed by and on the machine are properly authorized and audited
configuring, by the namespace controller, a namespace corresponding to the project name to permit the role to perform an action at the namespace in accordance with the policy(roles defined for a namespace define what actions each role is able to execute in the network ¶52,53, 80, 89)
[0052] In some embodiments, the access control service may manage “roles” (e.g., “admin” and “non-admin” roles) assigned to identities in the network environment. In a role-based access control (RBAC) system, permissions define the actions a role may be allowed to be performed on a network resource and can be assigned to roles in the context of a particular resource. Permissions models may govern access to access-protected network resources, such as secrets like database credentials, keys and passwords, in a uniform manner for users and hosts. As used herein, access-protected network resources are protected assets within an access control system that each possess a unique identifier (a resource ID). Rather than being defined directly, network resources may be defined by records that behave like network resources (e.g., users, groups, hosts, layers, variables, webservices, and possibly others). Non-limiting examples of network resources include database passwords, virtual machines and servers (e.g., for secure shell (SSH) management), and webservice endpoints. Network resources may be annotated with key-value pairs to facilitate organization and discovery through searching and display (e.g., using an access control system user interface).
[0053] The purpose of a role may be to possess privileges and to initiate transactions in a network environment. A role may represent a user, a person, a group, a host (such as a virtual machine or process), or a group of other roles. In addition to privileges being granted to a role, a role may be granted to another role so that the receiving role gains all the privileges of the granted role. In addition, the receiving role may gain all the roles which are held by the granted role (i.e., role grants are fully inherited). In some embodiments, roles are not defined directly. Rather, records that behave as roles, such as users, groups, hosts and layers may be used instead. A group can be a collection of users and/or other groups. When a user becomes a member of a group, the user is granted the group role and thus inherits the group's privileges. Because groups can also be members of groups, they may be organized and nested in a hierarchy.
[0080] In some embodiments, policies are self-contained and make no reference to records outside the policy. Thus, the policy may be loaded with different owner and namespace prefix options to serve different functions in a workflow. For example, a policy may be written and loaded into the access control system with full management assigned to a first namespace group (e.g., “developers”) and may also be loaded into a second namespace group (e.g., “production” or “operations”), creating a production version of the same policy. In some embodiments, the production version may have different permissions, modification rules and/or other changes. For example, a policy loaded into a developer group, may allow access to a large number of network resources than a policy loaded into a production group.
[0089] Thus objects, annotations, permissions and roles may be declared together inside an organizing element called a “policy” that may organize related things (e.g., roles, privileges, resource identifications, and more) together, and may isolate permissions to or from different parts of the access control system. For example, a database layer and database credentials (username and password) may be created together in an exemplary YAML policy:
[0090] The policy ID may also be a naming prefix (or “namespace”) for objects defined inside the policy (e.g., the full ID of the username above is “db/username”).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir/Enomoto with Gilpin’s use of API keys. The reason for this modification would be to ensure proper control and access to the deployed network.
The combination of Jahner/Tamir/Enomoto/Gilpin do not teach the secret in a path in a secrets manager at a path that is unique to the source repository, the project name and the environment of the application definition,
and by providing parameters to the secrets manager that specify the source repository, the project name and environment.
Blomquist in the same field of endeavor teaches a system for secrets management in a cloud deployment system. Blomquist teaches the secret in a path in a secrets manager at a path that is unique to the source repository, the project name and the environment of the application definition( a vault location i.e. repository is defined and individual paths to secrets for each project and environment within the project are defined for secrets storage, page 35 36),
and by providing parameters to the secrets manager that specify the source repository, the project name and environment(parameters secrets storage vault location and parameters such as project name and the environment( i.e. staging, review, stable), are defined using dynamic variables for each project , page 35,36).
4.2.2 Managing Vault Secrets
The Vault secrets can be added by people with the required permissions. OIDC
is an authentication protocol that stands for "OpenID Connect". It enables verifying
a user’s identity before granting access to certain endpoints. It is a further
developed version from OAuth and OpenID authentication methods. With OIDC
authentication, the Vault permissions will be linked to GitLab. This means that
employees with the required GitLab permissions can add the project specific secrets
to Vault using either Vault UI or the CLI. They can then add the project specific
secrets.
The secrets are stored in Vault under a mount called secrets/${project_name}-${track},
where the project_name and track are dynamic values. The Vault module of Kólga
supports secrets for review, staging and production environments (or tracks). The
mount paths for those environments go like the following:
• secrets/$project_name-$review
• secrets/$project_name-$staging
• secrets/$project_name-$stable
4.2.3 Vault Administration
Provisioning Vault can be done via Terraform, a popular IaC tool. Terraform contains
a provider for Vault, which makes the process of deploying and provisioning
Vault convenient. An important consideration when provisioning Vault with Terraform
is to note that secrets read or written by Terraform will also be persisted
in the Terraform state. This means that the Terraform state that is stored in a
tfstate-file, must be held behind strong encryption. The snippet below shows and
example how Vault can be configured using Terraform in a very minimal form. The
language used in the example is called Hashicorp Configuration Language (HCL).
provider " vault " {
address = " https : / / vault . example . net :8200"
}
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir/Enomoto/Gilpin with methods for the configuration of the secrets management system as taught by Blomquist. The reason for this modification would be to provide a secure system for controlling the development and deployment of applications.
Regarding claims 4 and 12, Jahner teaches wherein the secrets manager restricts access to the secret at the path to only the deployment service( the use of scoped paths in API calls to retrieve secrets restricts the application deployment system(ie deployer service ) to the path scoped for the particular application, ¶32,33, table 4 page 4).
[0032] Upon receiving a deployment manifest, a deployment director 102 of the application deployment system 204 parses the deployment manifest, identifies a secret name, and requests, from a credential manager 118, the secret values corresponding to the secret identifier. The credential manager 118 retrieves the secret values through the credential API, e.g., by using a “get” method, from the secret database 210. An example API method for retrieving secret values is provided below in Listing 4.
TABLE-US-00004 Listing 4: Example API for Getting Secret Values GET: [host]/[ver]/scope/[scope]/type/[secret type]/secret/[secret name] Response: { “scope”: [scope name], “secret-type”: [secret type], “values”: { “user”:[user name], “password”:[password] } }
[0033] Listing 4 illustrate an API where a “get” method for getting secret values. The “get” method can specify a host name, a version number, a scope, a secret type, and a secret name. In response to the “get” method, the credential manager 118 can retrieve the secret values corresponding to the secret name. The example API of Listing 4 allows devices or processes to set secret values programmatically.
Regarding claims 5 and 13, Jahner teaches wherein the secret allows the deployment service to be authorized to request the deployment manager to synchronize the application(deployment action using the system include updating changes to an existing deployed application, ¶41).
[0041] The application deployment system 204 can implement multiple graphical or command-line user interface items for various operators. For example, the application deployment system 204 implements administrator CLI 214, operator CLI 216, and security CLI 218. The user device 206, once authenticated, can access the application deployment system 204 through one or more of the administrator CLI 214, operator CLI 216, and security CLI 218 and receive user input through the administrator CLI 214, operator CLI 216, and security CLI 218.
[0046] An operator can update an existing deployment of an application. The user device 206 can receive a command from an operator CLI 216 to update a deployment manifest. The user device 206 then receives a deployment command, e.g., “bosh deploy.” The deployment director 102 can then substitute secret names in the updated deployment manifest as described above, and reconfigure the service instance accordingly.
Regarding claim 9, Jahner teaches the deployment manager to: authorize the request using the secret secrets contain credentials that authenticates and allows for deployment of service, ¶43)
[0043] Upon receiving each command described above, the application deployment system 204 performs corresponding operations. For example, upon receiving the command for deploying application, the application deployment system 204 configures a service instance according to a deployment manifest. The deployment director 102 authenticates with the credential manager using information in the deployment manifest that references a credential manager, for example, as described above in reference to Listing 7.
Enomoto teaches deploy, assuming the role, the application at the destination using the source repository(identity of user with respect to roles… i.e administrator/developer is determined and permission to perform modification to the network is implemented, ¶28)
[0028] After determining the user identity (and/or user credentials) associated with the workload deployment request, the access verification component 106 may verify that the user (and/or the device, network, etc.) is verified to access the workload 112 and associated objects within the source environment, and to modify/deploy the workload 112 within the destination environment. In some examples, the access verification component 106 may transmit requests to each of the source and destination computing environments, to verify that the user is authorized to perform the required operations within each of the computing environments. Such requests may include invoking APIs provided by the computing environments 114-116 and/or by the cloud service providers 122 to verify user authorization. In other instances, the access verification component 106 may access user lists maintained within the computing environments 114-116 to verify sufficient user authorization.
Regarding claim 17, Jahner teaches retrieve the secret from the secrets manager at the path using the parameters(deployment system queries secretes databased for secrets values corresponding to secrets specified in manifest, retrieval is performed using get calls ¶62)
[0062] The deployment director then modifies (408) the deployment manifest. Modifying the deployment manifest includes replacing each of the one or more secret names in the deployment manifest with a corresponding secret value received from the credential manager. In case the secret value is generated by the credential manager, the deployment director replaces the secret name with the generated by the credential manager.
[0063] The deployment director provisions (410) the resource for the application using the modified deployment manifest. In provisioning the resource, the deployment director creates a service instance for consumption by the application. The deployment director then binds the resource to the service instance. The service instance can include, for example, a virtual machine in which the application executes. Binding the resource to the service instance can include providing references and credentials for accessing the resource, e.g., addresses and ports of databases, database names, user names and passwords, to the virtual machine. The deployment manifest can be stored on disk. The modified deployment manifest can be stored in memory. The deployment director can delete the modified deployment manifest after the provisioning.
receive, from the deployment service, a request to deploy the application at the destination using the source repository, and the secret(deployer provisions service/application using deployment manifest that contain populated secret values, ¶s 62,63)
[0062] The deployment director then modifies (408) the deployment manifest. Modifying the deployment manifest includes replacing each of the one or more secret names in the deployment manifest with a corresponding secret value received from the credential manager. In case the secret value is generated by the credential manager, the deployment director replaces the secret name with the generated by the credential manager.
[0063] The deployment director provisions (410) the resource for the application using the modified deployment manifest. In provisioning the resource, the deployment director creates a service instance for consumption by the application. The deployment director then binds the resource to the service instance. The service instance can include, for example, a virtual machine in which the application executes. Binding the resource to the service instance can include providing references and credentials for accessing the resource, e.g., addresses and ports of databases, database names, user names and passwords, to the virtual machine. The deployment manifest can be stored on disk. The modified deployment manifest can be stored in memory. The deployment director can delete the modified deployment manifest after the provisioning.
authenticate and authorize the request using the secret(secrets contain credentials that authenticates and allows for deployment of service, ¶43)
[0043] Upon receiving each command described above, the application deployment system 204 performs corresponding operations. For example, upon receiving the command for deploying application, the application deployment system 204 configures a service instance according to a deployment manifest. The deployment director 102 authenticates with the credential manager using information in the deployment manifest that references a credential manager, for example, as described above in reference to Listing 7.
Enomoto teaches deploy the application at the destination using the source repository by assuming the role(identity of user with respect to roles… i.e administrator/developer is determined and permission to perform modification to the network is implemented, ¶28)
[0028] After determining the user identity (and/or user credentials) associated with the workload deployment request, the access verification component 106 may verify that the user (and/or the device, network, etc.) is verified to access the workload 112 and associated objects within the source environment, and to modify/deploy the workload 112 within the destination environment. In some examples, the access verification component 106 may transmit requests to each of the source and destination computing environments, to verify that the user is authorized to perform the required operations within each of the computing environments. Such requests may include invoking APIs provided by the computing environments 114-116 and/or by the cloud service providers 122 to verify user authorization. In other instances, the access verification component 106 may access user lists maintained within the computing environments 114-116 to verify sufficient user authorization.
Claims 2-3, 6-7. 10-11, 14, 15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jahner/Tamir/Enomoto/Gilpin/Blomquist as applied to claims 1, 8 and 16 above, and further in view of Miriyala US 2023/0336414.
Regarding claim 2, 10 and 18, Jahner/Tamir/Enomoto/Gilpin/Blomquist do not teach determining, by the namespace controller, that a namespace is created for a project having the project name. Blomquist teaches determining, by the namespace controller, that a namespace is created for a project having the project name.
[0056]If the same network policy also has namespaceSelector as namespace=myproject, then the corresponding firewall rule represents that namespace as (namespace=myproject). No other translations or rules representing pods in “myproject” namespace is done.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir/Enomoto with determining a project name of a namespace as taught by Miriyala. The reason for this modification would be correctly identify namespaces for implementation of network policies in a continuous deployment system.
Regarding claims 3 11 and 19, Jahner/Tamir/Enomoto/Gilpin/Blomquist do not teach:determining, by the namespace controller that the namespace was created for a project having the project name, wherein the configuring is performed in response to determining that the namespace was created. Miriyala in the same field of endeavor as the invention teaches a network policy generation and deployment. Miriyala teaches determining, by the namespace controller that the namespace was created for a project having the project name, wherein the configuring is performed in response to determining that the namespace was created(user created a namespace for application that is isolates the application in its namespace from other application namespaces, ¶95).
[0095] Container network interface (CNI) 17 configures virtual network interfaces for virtual network endpoints. The orchestrator 23 and container platform 19 use CNI 17 to manage networking for pods, including pod 22. For example, CNI 17 creates virtual network interfaces to connect pods to virtual router 21 and enables containers of such pods to communicate, via the virtual network interfaces, to other virtual network endpoints over the virtual networks. CNI 17 may, for example, insert a virtual network interface for a virtual network into the network namespace for containers in pod 22 and configure (or request to configure) the virtual network interface for the virtual network in virtual router 21 such that virtual router 21 is configured to send packets received from the virtual network via the virtual network interface to containers of pod 22 and to send packets received via the virtual network interface from containers of pod 22 on the virtual network. CNI 17 may assign a network address (e.g., a virtual IP address for the virtual network) and may set up routes for the virtual network interface. In Kubernetes, by default all pods can communicate with all other pods without using network address translation (NAT). In some cases, the orchestrator 23 and network controller 24 create a service virtual network and a pod virtual network that are shared by all namespaces, from which service and pod network addresses are allocated, respectively. In some cases, all pods in all namespaces that are spawned in the Kubernetes cluster may be able to communicate with one another, and the network addresses for all of the pods may be allocated from a pod subnet that is specified by the orchestrator 23. When a user creates an isolated namespace for a pod, orchestrator 23 and network controller 24 may create a new pod virtual network and new shared service virtual network for the new isolated namespace. Pods in the isolated namespace that are spawned in the Kubernetes cluster draw network addresses from the new pod virtual network, and corresponding services for such pods draw network addresses from the new service virtual network.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir/Enomoto/Gilpin/Blomquist with creating a namespace for each application(i.e. project) as taught by Miriyala. The reason for this modification would be provide isolation between different applications deployments.
Regarding 6, 14 and 20, Jahner/Tamir/Enomoto/Gilpin/Blomquist do not teach receiving, by the deployment manager from a project manager, a request to create the application definition for a project having the project name. Miriyala in the same field of endeavor as the invention teaches a network policy generation and deployment. Miriyala teaches receiving, by the deployment manager from a project manager, a request to create the application definition for a project having the project name(namespace created using a the characteristic(i.e. application definition) of the namespace, ¶91).
[0091] Kubernetes operates using a variety of Kubernetes objects - entities which represent a state of a Kubernetes cluster. Kubernetes objects may include any combination of names, namespaces, labels, annotations, field selectors, and recommended labels. For example, a Kubernetes cluster may include one or more “namespace” objects. Each namespace of a Kubernetes cluster is isolated from other namespaces of the Kubernetes cluster. Namespace objects may include at least one of organization, security, and performance of a Kubernetes cluster. As an example, a pod may be associated with a namespace, consequently associating the pod with characteristics (e.g., virtual networks) of the namespace. This feature may enable a plurality of newly-created pods to organize by associating the pods with a common set of characteristics. A namespace can be created according to namespace specification data that defines characteristics of the namespace, including a namespace name. In one example, a namespace might be named “Namespace A” and each newly-created pod may be associated with a set of characteristics denoted by “Namespace A.” Additionally, Kubernetes includes a “default” namespace. If a newly-created pod does not specify a namespace, the newly-created pod may associate with the characteristics of the “default” namespace.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir/Enomoto with creating a application definition with a project name as taught by Miriyala. The reason for this modification would be correctly identify namespaces for implementation of network policies in a continuous deployment system.
Regarding claim 7, 15, Jahner/Tamir/Enomoto/Gilpin/Blomquist do not specifically teach wherein the application definition name is unique to the source repository, the project name, and the environment. Miriyala in the same field of endeavor as the invention teaches a network policy generation and deployment. Miriyala teaches wherein the application definition name is unique to the source repository, the project name, and the environment.
[0097] CNI 17 may be invoked by orchestrator 23. For purposes of the CNI specification, a container can be considered synonymous with a Linux network namespace. What unit this corresponds to depends on a particular container runtime implementation: for example, in implementations of the application container specification such as rkt, each pod runs in a unique network namespace. In Docker, however, network namespaces generally exist for each separate Docker container. For purposes of the CNI specification, a network refers to a group of entities that are uniquely addressable and that can communicate amongst each other. This could be either an individual container, a machine/server (real or virtual), or some other network device (e.g. a router). Containers can be conceptually added to or removed from one or more networks. The CNI specification specifies a number of considerations for a conforming plugin (“CNI plugin”).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Jahner/Tamir/Enomoto/Gilpin/Blomquist with ensuring a project name of a namespace is uniqu