When it comes to SECRETS, how secure is your application?
Introduction Enterprises running various heterogeneous workloads ranging from on prem applications to applications spread across various cloud service providers, often struggle to manage credentials securely. We’ve seen a lot of technical debates about how to find a perfect balance between security and flexibility, but there’s no de facto standard hack which fits in for all. We’ve seen (sometimes radically) different opinions on “the right way” to manage secrets: “You should always use vault”, “You should encrypt creds” and the list is never ending! To cope up with these challenges, Veritas introduces Alta Recovery Vault short lived token-based authentication. For us, your data’s security is paramount to us. Prior to short lived tokens, Veritas provided ability to connect to Alta Recovery Vault with Standard Credentials (access and secret keys) as shown below : Diagram1: Creating a Credential with the Storage Account and Traditional Credentials (Access key and secret) given by Veritas Disadvantages of using Standard Credentials in Recovery Vault These standard credentials are long lived in nature. If compromised, they give attackers ample time to exploit the application. If they are stolen it would be a nightmare to discern which operations are legitimate. Thus, the only fail-safe choice is to cumbersomely rotate the keys and redistribute to customers. This is often overlooked action and adds extra pain for the DevOps.( p.s: It's not happier as it seems to be in the adajcent picture) Solution To help alleviate some of the above risks, Veritas has leveraged the ability to enhance security by introducingshort lived token-based authentication. Beginning with NetBackup 10.2 for Azure and NetBackup 10.4 for AWS (...GCP work in progress), users will have cloud storage accounts and a short-lived refresh token to connect securely to the Alta Recovery Vault storage. These new secrets are added as Credentials in the NetBackup Credential Management (as shown in diagram 2a and 2b) Once the initial connection is established, Veritas credential Management API is solely responsible for renewing, refreshing, accessing and sharing access signature. Isn’t it amazing just no pain to rotate the keys and redistribute! ( I see the cyber security team seems happier and overjoyed ) Diagram 2a: Creating a Credential with the Storage Account and Refresh Token given by Veritas for Azure Diagram 2b: Creating a Credential with the Refresh Token given by Veritas for AWS Solution Benefits Enhanced Security : Short-lived tokens have a limited lifespan, reducing the exposure window for potential attacks. If a token is compromised, its validity period is short, minimizing the risk of unauthorized access. Regular token expiration forces users to re-authenticate, ensuring better security. Mitigating Token Abuse : Tokens are often used to authorize access to resources. By making tokens short lived, we limit the time an attacker can use to abuse a stolen token. Thus, minimizing the risk window significantly. Better Management of Permissions : When permissions change (e.g., user roles or access levels), short-lived tokens automatically reflect the updates upon renewal. Long-lived tokens may retain outdated permissions, leading to security risks. Conclusion Introduction to Alta Recovery Vault short lived token authentication adds another layer for ransomware protection thus making applications more secure than ever before. At Veritas, your data’s security is paramount to us and this blog serves just as one simple example of the challenges Veritas short lived tokens can help solve. Further, Veritas is always looking and working for better ways to secure your data. Here are some additional helpful links : Veritas Alta Recovery Vault Technical White Paper Veritas Alta Recovery Vault Security Guide Veritas Alta Recovery Vault Azure ExpressRoute Overview Guide Veritas Alta™ Recovery Vault AWS Direct Connect Overview Guide Please feel free to give feedback and we can answer any queries !! Appreciate everyone time :)NetBackup 10.1 - New PaaS Workload Protection
Starting with NetBackup 10, Veritas began expanding the support for PaaS workloads. In NetBackup 10.1, Veritas built an extensive framework designed to promote accelerated adoption of PaaS workloads protection. As a testament to that framework, NetBackup 10.1 adds support for the following 13 new PaaS workloads: Azure Workloads AWS Workloads GCP Workloads Azure PostgreSQL Amazon RDS Postgres Google MySQL Azure MySQL Amazon RDS MySQL Google PostgreSQL Azure Managed SQL Amazon RDS MariaDB Azure SQL Amazon Aurora SQL Azure MariaDB Amazon Aurora PostgreSQL Amazon DynamoDB The process of protecting and recovering PaaS workloads is easy and streamlined via NetBackup Web UI. NetBackup Snapshot Manager needs to be configured to facilitate the discovery of the supported PaaS workloads. Media Server with MSDP Universal Share configuration is also a requirement. After NetBackup Snapshot Manager and cloud provider credentials are configured, discovery process will be triggered automatically or can be started manually. Once the discovery runs successfully, supported workloads will be populated on the Web UI PaaS tab: Add PaaS credentials as required for the workloads to be protected. Credentials can be created previously and leveraged later for the workload to be protected or created as new during configuration. On this example, credential is being created previously using Credential Management tab: Add the credential to the PaaS workloads to be protected. Please note the “validation host” is the Media Server hostname that will be utilized to communicate with the cloud provider and PaaS workload. Media Server need to be able to resolve PaaS services to validate credentials: After that, it is just a matter of creating Protection Plan as usual. The following two prompts are specific to PaaS workloads: 1-) Protection Plan is for Cloud, same as the one used to protect virtual machines in the Cloud, for example. Check “Protect PaaS assets only” to be able to call the correct workflow and framework for PaaS: 2-) On step 4 (Backup options), storage path is the previously configured Universal Share mount point: Just complete Protection Plan workflow and that’s it! Protection Plan will run according to the schedule configuration and recoveries will be fully managed by NetBackup Web UI as well. Veritas NetBackup 10.1 now makes it easier to protect PaaS workloads, with a streamlined process guided by Web UI and leveraging benefits of NetBackup deduplication service (MSDP) and RBAC (role-base access control) to empower workload owners and administrators as needed. Here are some good references for more information about PaaS Workload protection with NetBackup 10.1: NetBackup 10.1 Web UI Cloud Administrator's Guide - Protecting PaaS objects NetBackup 10.1 Web UI Cloud Administrator's Guide - Recovering PaaS assetsPart 1: Deploying NetBackup in the Google Cloud Platform (GCP)
In the following example, NetBackup 9.1 Primary, Media and CloudPoint servers are deployed with the result being able to log into the NetBackup Primary WebUI and viewing the Media and CloudPoint servers attached. Let’s Begin To begin, log into your GCP portal and search for Veritas NetBackup in the GCP navigation bar and select “Veritas NetBackup 9.1”. You will be taken to the NetBackup 9.1 deployment page that gives an overview of the NetBackup software. Click Launch to continue. Primary Server Deployment Enter a deployment name to identify it. Choose which Google Zone you’d like your deployment installed in. Next, we’ll choose the machine type we’d like for our NetBackup Primary server. The size of your environment will vary greatly depending on your backup needs. For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 Choose the type of boot disk and the size you’d like NetBackup to run on. For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 Now we’ll enter in the networking rules for our Primary server. For more information regarding firewall port requirements for NetBackup, see the Veritas NetBackup Ports Reference Guide. https://www.veritas.com/content/support/en_US/doc/80731497-149899093-0/v124789571-149899093 Adjust the default network interface and/or add an additional network interface. Enter the source IP or range that can access the new server for SSH. Enter the source IP or range that can access the new server for HTTPS. Enter the source IP or range that can access the new server for VNETD. Enter the source IP or range that can access the new server for RESTful. Enter the source IP or range that can access the new server for VERITAS_PBX. Next, we’ll enter the installation parameters. These steps determine if we’re deploying a Primary or Media server. First, we’ll deploy a Primary server and then return to install our Media server. Select “primary” to deploy the Primary server. Give the Primary a hostname. Ignore the Media Server Hostname for now. Enter a service username. This is not a user that will be able to log into the environment. This user will only be used to start and stop NetBackup processes. Enter in a domain the new Primary will live in. Select true or false if there is a hosted zone created for the domain name in step 5. If you select false, the deployment will create the hosted zone. Next we need to provide the new hosted zone name or the name of the existing hosted zone. Enter in your NetBackup license key. Ignore the Media Server Token for now. Enter in your NetBackup Usage Insights Key. Lastly, before we deploy, select if you’d like Stackdriver logging and monitoring. Accept the Terms of Service and click Deploy. Now that the Primary has been deployed, we will deploy the Media server. Media Server Pre- Requirements To build our Media server and have it join the Primary, we need to generate a token from the Primary server. If you choose not to use the root user to log into the WebUI, a user must be created and given privileges to login to the WebUI. From Compute Engine > Instances use the remote access capability and log into the new Primary server. Create a new user that will log into the new NetBackup infrastructure. sudo useradd -m newusername sudo passwd newusername sudo /usr/openv/netbackup/bin/admincmd/bpnbaz -AddRBACPrincipal -user typeofpassword:FullyQualifiedDomainName:username Example: sudo useradd -m netbkadmin sudo passwd netbkadmin sudo /usr/openv/netbackup/bin/admincmd/bpnbaz -AddRBACPrincipal -user unixpwd:ng-nbu-primary1.vrts.tme.io:netbkadmin Next open a web browser and type this into the URL bar: https://FQDN/webui Example: https://ng-nbu-primary1.vrts.tme.io/webui Enter the username and password created in step 1. On successful login you will be greeted with the following banner. Click the X in the upper right corner. Click on Tokens in the WebUI and create a new token and copy the Token Value. We will need that value when we deploy our Media server. Copy the Token Value and save it for later. Go back to the GCP MarketPlace, search for Veritas NetBackup like we did for the Primary server deployment and Launch another NetBackup 9.1 deployment. Media Server Deployment Enter a deployment name to identify it. This will be different from the Primary server deployment name. Choose which Google Zone you’d like your deployment to installed in. Next, we’ll choose the machine type we’d like for our NetBackup Media server. The size of your environment will vary greatly depending on your backup needs. For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 Choose the type of boot disk and the size you’d like NetBackup to run on. For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 Now we’ll enter in the networking rules for our Media server. For more information regarding firewall port requirements for NetBackup, see the Veritas NetBackup Ports Reference Guide. https://www.veritas.com/content/support/en_US/doc/80731497-149899093-0/v124789571-149899093 Adjust the default network interface and/or add an additional network interface. Enter the source IP or range that can access the new server for SSH. Enter the source IP or range that can access the new server for HTTPS. Enter the source IP or range that can access the new server for VNETD. Enter the source IP or range that can access the new server for RESTful. Enter the source IP or range that can access the new server for VERITAS_PBX. Next we’ll enter the installation parameters for our Media server. Select “media” to deploy the Media server. Enter the Primary name given in the previous deployment. Enter a name for the Media server. Enter a service username. This is not a user that will be able to log into the environment. This user will only be used to start and stop NetBackup processes. Enter the domain we used for the Primary. Select true since we created the zone previously or with the Primary deployment. Provide the existing hosted zone name. Enter in your NetBackup license key. Put in the media server token generated from the Primary server in Media Server Pre-Requirements, step 6. Enter in your NetBackup Usage Insights Key. Lastly, before we deploy, select if you’d like Stackdriver logging and monitoring. Accept the Terms of Service and click Deploy. Now that the Media server has been deployed, we will validate the Media server has been added to the Primary server and deploy the CloudPoint server.Part 2: Deploying NetBackup in the Google Cloud Platform (GCP)
Validate Primary and Media Servers in NetBackup Now that the Primary and Media servers have been created, we will log into NetBackup to check on the status of the Primary and Media. In the NetBackup WebUI, click on Security > Hosts in the left navigation panel. Ensure the Primary and Media are listed. CloudPoint Server Deployment After the Primary and Media servers have been deployed and validated that they are listed in Hosts, it’s time to deploy the CloudPoint Sever. Search for Veritas NetBackup Cloudpoint and select Veritas NetBackup CloudPoint 9.1. Click on Launch to launch the NetBackup CloudPoint 9.1 deployment. Give the CloudPoint deployment a name and select the OS Image. Choose the Machine Type CloudPoint will run on. For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide and Veritas NetBackup CloudPoint Install and Upgrade Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 https://www.veritas.com/content/support/en_US/doc/140789355-148057836-0/v141580670-148057836 Select the type and size of the Boot Disk CloudPoint will run on. For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide and Veritas NetBackup CloudPoint Install and Upgrade Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 https://www.veritas.com/content/support/en_US/doc/140789355-148057836-0/v141580670-148057836 Enter the size of the CloudPoint Data Disk. If you are doing an upgrade, the “Cloudpoint Data Disk” is where your existing CloudPoint Data Disk is located. For Example: /cloudpoint For more information on sizing your NetBackup environment, see NetBackup Backup Planning and Performance Tuning Guide and Veritas NetBackup CloudPoint Install and Upgrade Guide. https://www.veritas.com/content/support/en_US/doc/21414900-146141073-0/v146020053-146141073 https://www.veritas.com/content/support/en_US/doc/140789355-148057836-0/v141580670-148057836 Select the Zone that CloudPoint will be installed in. Choose the Network interfaces for your CloudPoint deployment. Enter the source IP address range that will be able to access the CloudPoint server. This is needed for RabbitMQ traffic. Enter the source IP address range that will be able to access the CloudPoint server. This is needed for HTTPS traffic. Enter in the service account ID that has Editor and Secret Manager Secret Accessor roles attached to it. These are needed during the CloudPoint creation. If no name is entered, the default GCP account user will be used. Enter in an SSH public key to this instance if one exists. Enter in the username for NetBackup CloudPoint. Note - This will be used later to add CloudPoint to the Primary server. Note - The password for this user can be retrieved on the CloudPoint deployment page. Enter in any other names or aliases that need to be part of the TLS certificate. Enter the port CloudPoint will use. If you would like regular snapshots of CloudPoint, click the checkbox. A client email address must be entered to enable regular snapshots. The Private Key Secret is a secret name which stores the service account private key. Confirm that the Secret Manager API has been enabled, accept the Terms of Service and click on Deploy. NetBackup CloudPoint has been successfully deployed; these warnings can be ignored. Add CloudPoint Server to Primary After a successful CloudPoint server deployment, we need to add the CloudPoint server to the NetBackup Primary server. Retrieve the name of your newly created CloudPoint server from the VM instance in GCP. Log into the WebUI of the Primary server created earlier in the document. Navigate to Workloads > Cloud > CloudPoint servers. Click on the + Add button to add the newly created CloudPoint server. Enter the name of the server collected in Step 1. Enter the port selected during the CloudPoint install. Click on the Validate button. Click on the Accept button. Enter in the username for CloudPoint created earlier in this document. Enter in the password for this user and click on the Add button in the lower right corner. Note – The link to the password can be found on the deployment page for the CloudPoint server. Navigate to Security > Hosts and we can see all three of the created components successfully registered with the Primary.
CloudPoint deployed in GCP and integration with NetBackup
Hello, I am trying to integrate my CloudPoint instance deployed on Google CP with my NetBackup Master Server on-premise. For some reason I got the following message error when I try to add the CloudPoint from CLI on a Master Sever: [xxx@backup logs]# /usr/openv/volmgr/bin/tpconfig -add -cloudpoint_server xxxxx.bc.googleusercontent.com -cloudpoint_server_user_id <user> Enter the CloudPoint Server host's password for User Id <user>:Please re-enter the CloudPoint Server host's password to confirm it:Authenticity of root certificate cannot be established. The SHA1 fingerprint of root certificate is 7E:27:4D:C7:E2:4F:28:FA:F4:43:04:BD:DB:0F:D7:DC:1C:16:12:CF. Are you sure you want to continue using this certificate ? (y/n): Y The validation of root certificate fingerprint is successful.CloudPoint server login failed. Could not validate the provided credentials. Not network issues, I can do ping via 443 port from my on-premise server. If I try to do it from the GUI using the IP address (not supported) or the Name, I got the error "unable to connect to the CloudPoint server: Connection refused. Verify that CP is up and running". Maybe is not supported? Any help or idea will be appreciated. Many thanks.
