I have been tasked with developing a service that takes requests for admin access to a windows server, receives approval from management, grants access, and then automatically revokes access after an hour.
I am required to do all deployments through Octopus Deploy.
I cannot store the super user password within the service, since all developers have read access to our SVN.
I was planning on storing the password within a secure variable in Octopus Deploy, but then realized that anyone with modification permissions on the project could add a powershell script to send themselves the variable values.
Is there any way to secure a variable within Octopus Deploy that can be used to install a windows service with super user access, but cannot be retrieved by any means?
How I have this setup uses a combination of roles and environments to limit access to sensitive variables such as prod passwords.
You need two roles:
1) is a project editor role that allows developers to do everything but only for Dev/UAT environments. This allows them to get everything ready and tested without access to the prod environment.
2) a production editor role which only a few people have access to. Production password variables are scoped to the Prod environment so developers can't access them.
Related
I am planning to build an enterprise application using aws lambda and serverless framework.
I want to separate the dev, test and prod environments and I am planning to use AWS Parameter store for it.
I don't want my production environment configuration be exposed to developers. If the developer runs the command serverless offline -s production start then the production configuration should not be obtained.
It should be obtained only when the serverless function has been successfully deployed to aws lambda.
Here are few considerations based on your question:
To have different environments on Serverless framework you have to set up the stage. This value can be passed as a parameter when executing sls commands.
If you are keeping your code in a repo, the developers will have access to all the configurations. If this is really important, you could keep the production configuration in a diff repo where only very specific people will have access to it, and then you make a reference to in in your serverless.yml. Ex:
custom: ${file(./config/${opt:stage, 'dev'}.json)} and then in your config folder you create the prod.json file, but pointing to the real one of the new repo you created. Note: this would make your project harder to maintain.
Considering you don't want your developers to execute your production environment locally. You can use the global variable of serverless offline to block the execution. You could also inform then to not do so.
Here is what should be a good practice and solution based on your problem:
Considering you have a production environment you want to isolate from a given group in your company, you should create VPC's and configure their resources access, accordingly.
Then you create users to have diff access. When your developer try to execute the code accessing a resource (dynamoDB for example) in a VPC they don't have access, they will be blocked.
AWS configure to define which user will execute the SLS command.
Your development team will still have access to your configuration file.
Note: In this case the person/group with access to the production VPC will have to do the deploy.
If the answer does not suffice, could you please reinforce which type of resource(s) are sensitive across your Serverless project? I am taking for granted it is the DB as it is the most common scenario.
I'd like to enable guest access to our TeamCity server so that our operations team can see if a deployment build is currently underway, as they do testing and during a deployment the environment becomes unstable.
It looks like the very base View Projects role assigned to guest still allows users to download artifacts, see the build log and unit test results. Since the artifacts are the software we develop, which is commercial, we can't have anonymous access allowing downloading of our code.
How can I further restrict the guest account to only be able to see if a build is running? If its not possible, I'll accept that as well, and will probably just make a shared logon for them, but it'd be nicer just to enable guest.
We're using TC 2017.1.3.
you cannot do that. Give access for guest user is bad idea.
You have to create other user and give special rights.
We currently use TeamCity to build a deployment artifact, then a further TeamCity task takes that artifact and deploys it to our development and testing servers on demand.
We can store the passwords and other secret data in properties files that we can check into source control, as these are all internal servers and the developers have full access to them.
However for release to Production (and our final test layer) there are secret passwords and configuration that we don't want checked into the normal source control, or to have development be able to discover the passwords. So to do 'real' deployments we have to hand the artifact over to another team and they maintain a properties file with the production values.
What methods exist to store these secrets and allow TeamCity to run a deploy without ever leaking the secrets out?
(note I am one of the devs and it is not a trust issue... I don't want to have the ability to find out prod passwords so I can never accidently know them and do some horrific damage!)
Probably what you need here, is to create a separate project with narrower scope of permissions (for example, allow only certain people to edit build configurations). In this project create a build configuration, responsible for deployment. In this configuration, you can define a Typed Parameter of type 'password' to store the password to the production environment.
Another option is to use Deployer Plugin, especially its ability to deploy over ssh with private key authentication
If you are OK to use a third party solution, consider using a solution like CloudMunch which can help you to perform release management functions with these secure parameters collected at deploy time and encrypted post deployment.
Disclaimer: I work with CloudMunch
You can do 2 things.
Use a teamcity project to deploy artefacts for production only. This will only be accessible to ops members.
Teamcity also supports running agents with different user ids. You can create a new user id which can have access to the production "secrets" (passwords and configuration). Use this id to run the targets in the 1st step.
One of my clients wants to understand IAM feature before migrating business application to Amazon cloud.
I have figured out two use cases which we can recommend to our client, these are:
Resource-Level Permissions for EC2
• Allow users to act on a limited set of resources within a larger, multi-user EC2 environment.
• Control which users can terminate which instances.
• Restricting a user access to a single EC2 instance ( currently not supported by amazon API’s)
IAM Roles for Amazon ec2 resources
Command Line Usage
• Unix/Linux/Windows - Use the AWS Command Line Interface, which is a unified tool to manage the AWS services. We can access the Command Line Interface using the EC2 instance launched with IAM role support without specifying the credentials explicitly.
Programmatic Usage
• Use the appropriate AWS SDK for your language of choice. Configure it without specifying the credentials.
I would like to know other capabilities of IAM which we can recommend to our client and other use cases which you can recommend to us. Please let us know if any further explanation is required.
Any prompt response will be highly appreciated.
Thanks in advance
This is a very useful feature of AWS !
User Management - If you are a large team, you will have to give different users (or developers/testing, deployment) different type of permissions. Access levels like (say S3 read-only, DynamoDB full-access etc).
Manage Users : http://aws.amazon.com/iam/details/manage-users/
Not to keep credentials in code. Is you use IAM roles, you can mention that say an EC2 should work on this role. This will help you achieve things like "cluster with only access to S3, not DB")
IAM Roles for Amazon EC2 - Amazon Elastic Compute Cloud : http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
Handle Release staging. This is a benefit from the ROLE. You move apps from dev, qa, staging and prod. I usually keep different accounts for this. In this case, if you configure the EC2 to run on roles, then the stage difference can be handled witout code change. Just move the build from one account to another, and it works with no risk!
Lot of other benefits;
Product Details : http://aws.amazon.com/iam/details/
I want to setup a Windows Azure development storage on my dev machine but I don't want to install SQL server on it because I want to use an existing one on another machine. Is it possible to set up the development storage service so that it uses the SQL server from another machine?
I tried calling dsinit with the /sqlinstance argument set to the remote machine, but it doesn't have any argument to allow me to specify the login credentials.
You can use undocumented command line argument /server:.
Example: dsinit /server:remote-sql-name
Added reservation for http://127.0.0.1:10000/ in user account DOMAIN\username.
Added reservation for http://127.0.0.1:10001/ in user account DOMAIN\username.
Added reservation for http://127.0.0.1:10002/ in user account DOMAIN\username.
Creating database DevelopmentStorageDb20110816...
Granting database access to user DOMAIN\username...
The login already has an account under a different user name.
Changed database context to 'DevelopmentStorageDb20110816'.
Adding database role for user DOMAIN\username...
User or role 'user' does not exist in this database.
Changed database context to 'DevelopmentStorageDb20110816'.
Initialization successful. The storage emulator is now ready for use.
I think the short answer is no. Certainly dsinit is designed to only work on your local machine.
Can you setup the remote database server to use windows authentication and add the currently logged in user as an admin on that server? That may be enough to fool it (but I wouldn't hold my breath)
If this doesn't work and you still don't want to SQL on your development machine, then using the actual Azure storage is not a bad idea. It does cost some money, but not much and it does avoid some of the kinks that occur only in development storage.