Abstract: The disclosed technology is generally directed to code transparency. In one example of the technology, evidence associated with a policy is obtained. The evidence includes data that includes cryptographically verifiable evidence associated with initial source code in accordance with the policy. The initial source code is source code for a CTS. The initial binary is based on the initial source code is executed in a TEE such that a CTS instance begins operation. The CTS instance is configured to register guarantee(s) associated with code approved by the CTS instance. The TEE is used to provide a ledger. The evidence is stored on the ledger. Measurement(s) associated with the binary are provided. A service key associated with CTS instance is generated. TEE attestation of the measurement(s), the evidence, and the service key is provided.

Abstract: The disclosed technology is generally directed to code transparency. In one example of the technology, a claim associated with an application is received. The claim is a document that is signed with a claim signature and that includes evidence associated with a policy, and further includes an expected set of at least one binary measurement associated with the application. The evidence is cryptographically verifiable evidence associated with the application. A trusted execution environment (TEE) is used to provide a distributed ledger. The claim is verified. Verifying the claim includes verifying the expected set of at least one binary measurement associated with the application, verifying the claim signature, and, based at least on the evidence, verifying that the application meets the policy. Upon successful verification of the claim, the claim is appended to the distributed ledger. A ledger countersignature associated with the claim is generated.

Abstract: Methods, systems, and computer storage media for providing access to computing environments based on a multi-environment policy are provided. The a multi-environment policy is configurable to define rules that have provider-controlled and customer-controlled computing environment parameters for approving access to provider-controlled computing environments and customer-controlled computing environments. In operation, a request associated a computing environment are received. The computing environment is associated with a multi-environment policy. The multi-environment policy is configurable to define the rules based on access vectors having grouped computing environment aspects for control and visibility associated with accessing computing environments. Based on the request, a determination whether the request is for a provider-controlled or a customer-controlled computing environment is made.

Abstract: Various methods and systems are provided for autonomous orchestration of secrets renewal and distribution. A secrets management service (“SMS”) can be utilized to store, renew and distribute secrets in a distributed computing environment. The secrets are initially deployed, after which, SMS can automatically renew the secrets according to a specified rollover policy, and polling agents can fetch updates from SMS. In various embodiments, SMS can autonomously rollover client certificates for authentication of users who access a security critical service, autonomously rollover storage account keys, track delivery of updated secrets to secrets recipients, deliver secrets using a secure blob, and/or facilitate autonomous rollover using secrets staging. In some embodiments, a service is pinned to the path where the service's secrets are stored. In this manner, secrets can be automatically renewed without any manual orchestration and/or the need to redeploy services.

Abstract: Methods, systems, and computer storage media for providing access to computing environments based on a multi-environment policy are provided. The a multi-environment policy is configurable to define rules that have provider-controlled and customer-controlled computing environment parameters for approving access to provider-controlled computing environments and customer-controlled computing environments. In operation, a request associated a computing environment are received. The computing environment is associated with a multi-environment policy. The multi-environment policy is configurable to define the rules based on access vectors having grouped computing environment aspects for control and visibility associated with accessing computing environments. Based on the request, a determination whether the request is for a provider-controlled or a customer-controlled computing environment is made.

Abstract: Various methods and systems are provided for autonomous signing management for a key distribution service (“KDS”). In operation, a key request from a KDS client device is received at a KDS server. The key request is associated with a security token of a signing entity caller or verifying entity caller, and a signature descriptor. The signature descriptor supports signing data with an encryption key and verifying a signature with a decryption key. The signing entity caller or the verifying entity caller is authenticated based on the corresponding security token and signature descriptor. The encryption key or the decryption key associated with the key request is generated. The encryption key or the decryption key is generated based on authenticating using the security token and the signature descriptor. The encryption key or the decryption key is communicated to a KDS client device the KDS client to sign data or decrypt a signature.

Abstract: Various methods and systems are provided for autonomous orchestration of secrets renewal and distribution. A secrets management service (“SMS”) can be utilized to store, renew and distribute secrets in a distributed computing environment. The secrets are initially deployed, after which, SMS can automatically renew the secrets according to a specified rollover policy, and polling agents can fetch updates from SMS. In various embodiments, SMS can autonomously rollover client certificates for authentication of users who access a security critical service, autonomously rollover storage account keys, track delivery of updated secrets to secrets recipients, deliver secrets using a secure blob, and/or facilitate autonomous rollover using secrets staging. In some embodiments, a service is pinned to the path where the service's secrets are stored. In this manner, secrets can be automatically renewed without any manual orchestration and/or the need to redeploy services.

Abstract: Various methods and systems are provided for autonomous orchestration of secrets renewal and distribution across scope boundaries. A cross-scope secrets management service (“SMS”) can be utilized to store, renew and distribute secrets across boundaries in a distributed computing environment such as regional boundaries. In some embodiments, locally scoped secrets management services subscribe to receive updates from the cross-scope secrets management service. As secrets are renewed, they are automatically propagated to a subscribing local scope and distributed by the local secrets management service. In various embodiments, SMS can autonomously rollover storage account keys, track delivery of updated secrets to secrets recipients, deliver secrets using a secure blob, and/or facilitate autonomous rollover using secrets staging. In some embodiments, a service is pinned to the path where the service's secrets are stored.

Abstract: Various methods and systems are provided for autonomous secrets management for a key distribution service (“KDS”). A KDS server performs centralized management and distribution of keys for client devices in a distributed computing system, which obviates key management and distribution at the client devices. In operation, a key request is received at a KDS server from a KDS client device. The key request is generated using a data protector and a KDS client component of the KDS client device. The key request is associated with a caller and a security token of the caller. The caller is authenticated at a security token service (STS) based on a security token. An encryption key or decryption key associated with the key request is generated. The encryption key or the decryption key is generated based on an interval-based key derivation scheme. The encryption key or the decryption key is communicated to KDS client.

Abstract: A compute resource provider system is shown having an encryption agent that obtains a cryptographic key for a virtual machine and sends the cryptographic key to a host agent. The host agent receives the cryptographic key from the encryption agent and stores the received cryptographic key to a user key vault. The host agent generates a key vault secret reference (KVSR) locator pointing to the cryptographic key stored in the user key vault, associates the KVSR with the virtual diskset, and sends a success message to the encryption agent. The encryption agent receives the success message from the host and, responsive thereto, encrypts the virtual diskset using the cryptographic key. Subsequently, another host agent uses the KVSR to obtain the cryptographic key from the key vault and boot the virtual machine with the encrypted virtual diskset.

Abstract: Methods, systems, and computer storage media for providing access to computing environments based on a multi-environment policy are provided. The a multi-environment policy is configurable to define rules that have provider-controlled and customer-controlled computing environment parameters for approving access to provider-controlled computing environments and customer-controlled computing environments. In operation, a request associated a computing environment are received. The computing environment is associated with a multi-environment policy. The multi-environment policy is configurable to define the rules based on access vectors having grouped computing environment aspects for control and visibility associated with accessing computing environments. Based on the request, a determination whether the request is for a provider-controlled or a customer-controlled computing environment is made.

Abstract: Aspects of the technology described herein enable a client device to access a web service in a claims-based identity environment thorough an Internet Protocol (IP) address, rather than the web service's domain name service (DNS). In a claims-based identity environment, a client device will authenticate a relying party's server SSL certificate before providing the token to the relying party by following an authentication process. Current authentication processes include a name-chaining operation, which compares a subject field of a token provided with the Uniform Resource Identifier (URI) used to request the resource (e.g., RP application). When the IP address is used as the URI, then the URI in the certificate will not match the URI in the request and the authentication will fail. Accordingly, aspects of the technology use an alternative authentication method that allows access to a web service through an IP address, when the default client-side token validation is DNS-name based.

Abstract: Various methods and systems are provided for autonomous management for a managed service identity. A first token request, for a secret, is generated at a managed service. The secret supports authenticating the managed service for performing operations in a distributed computing environment. The first token request includes an identity identifier of the managed service. The first token request is communicated to a credentials manager which is associated with a secrets management service (“SMS”) that can be utilized to store, renew and distribute secrets in the distributed computing environment. Based on communicating the first token request to credentials manager, the token is received, via the credentials manager, from the secret token service. The token is received based in part on the credentials manager generating a second token request for the token and communicating the second token request and a secret associated with the managed service to the secret token service.

Abstract: Various methods and systems are provided for autonomous signing management for a key distribution service (“KDS”). In operation, a key request from a KDS client device is received at a KDS server. The key request is associated with a security token of a signing entity caller or verifying entity caller, and a signature descriptor. The signature descriptor supports signing data with an encryption key and verifying a signature with a decryption key. The signing entity caller or the verifying entity caller is authenticated based on the corresponding security token and signature descriptor. The encryption key or the decryption key associated with the key request is generated. The encryption key or the decryption key is generated based on authenticating using the security token and the signature descriptor. The encryption key or the decryption key is communicated to a KDS client device the KDS client to sign data or decrypt a signature.

Abstract: Various methods and systems are provided for autonomous secrets management for a temporary shared access signature (“SAS”) service. Input for a temporary access request for an account resource, is received from a client. The temporary access request is validated, based on communicating a validation request to the secrets management service (“SMS”) that can be utilized to store, renew and distribute secrets in a distributed computing environment. Validating the temporary access request is based on determining a storage account location path for SAS keys that provide temporary access to account resources. An access policy associated with the temporary access request is accessed. An SAS key request, associated with temporary access request, is communicated to the SMS. The SAS key request includes at least a portion of the access policy. An SAS key is received from the SMS. The SAS key, for access to the account resource, is communicated to the client.

Abstract: Various methods and systems are provided for autonomous secrets management for a key distribution service (“KDS”). A KDS server performs centralized management and distribution of keys for client devices in a distributed computing system, which obviates key management and distribution at the client devices. In operation, a key request is received at a KDS server from a KDS client device. The key request is generated using a data protector and a KDS client component of the KDS client device. The key request is associated with a caller and a security token of the caller. The caller is authenticated at a security token service (STS) based on a security token. An encryption key or decryption key associated with the key request is generated. The encryption key or the decryption key is generated based on an interval-based key derivation scheme. The encryption key or the decryption key is communicated to KDS client.

Abstract: A compute resource provider system is shown having an encryption agent that obtains a cryptographic key for a virtual machine and sends the cryptographic key to a host agent. The host agent receives the cryptographic key from the encryption agent and stores the received cryptographic key to a user key vault. The host agent generates a key vault secret reference (KVSR) locator pointing to the cryptographic key stored in the user key vault, associates the KVSR with the virtual diskset, and sends a success message to the encryption agent. The encryption agent receives the success message from the host and, responsive thereto, encrypts the virtual diskset using the cryptographic key. Subsequently, another host agent uses the KVSR to obtain the cryptographic key from the key vault and boot the virtual machine with the encrypted virtual diskset.

Abstract: Various methods and systems are provided for autonomous secrets management for a temporary shared access signature (“SAS”) service. Input for a temporary access request for an account resource, is received from a client. The temporary access request is validated, based on communicating a validation request to the secrets management service (“SMS”) that can be utilized to store, renew and distribute secrets in a distributed computing environment. Validating the temporary access request is based on determining a storage account location path for SAS keys that provide temporary access to account resources. An access policy associated with the temporary access request is accessed. An SAS key request, associated with temporary access request, is communicated to the SMS. The SAS key request includes at least a portion of the access policy. An SAS key is received from the SMS. The SAS key, for access to the account resource, is communicated to the client.

Abstract: Various methods and systems are provided for autonomous orchestration of secrets renewal and distribution. A secrets management service (“SMS”) can be utilized to store, renew and distribute secrets in a distributed computing environment. The secrets are initially deployed, after which, SMS can automatically renew the secrets according to a specified rollover policy, and polling agents can fetch updates from SMS. In various embodiments, SMS can autonomously rollover client certificates for authentication of users who access a security critical service, autonomously rollover storage account keys, track delivery of updated secrets to secrets recipients, deliver secrets using a secure blob, and/or facilitate autonomous rollover using secrets staging. In some embodiments, a service is pinned to the path where the service's secrets are stored. In this manner, secrets can be automatically renewed without any manual orchestration and/or the need to redeploy services.

Abstract: Various methods and systems are provided for autonomous management for a managed service identity. A first token request, for a secret, is generated at a managed service. The secret supports authenticating the managed service for performing operations in a distributed computing environment. The first token request includes an identity identifier of the managed service. The first token request is communicated to a credentials manager which is associated with a secrets management service (“SMS”) that can be utilized to store, renew and distribute secrets in the distributed computing environment. Based on communicating the first token request to credentials manager, the token is received, via the credentials manager, from the secret token service. The token is received based in part on the credentials manager generating a second token request for the token and communicating the second token request and a secret associated with the managed service to the secret token service.